Network Working Group M. Lind
Request for Comments: 4029 TeliaSonera
Category: Informational V. Ksinant
Thales Communications
S. Park
SAMSUNG Electronics
A. Baudot
France Telecom
P. Savola
CSC/Funet
March 2005
Network Working Group M. Lind
Request for Comments: 4029 TeliaSonera
Category: Informational V. Ksinant
Thales Communications
S. Park
SAMSUNG Electronics
A. Baudot
France Telecom
P. Savola
CSC/Funet
March 2005
Scenarios and Analysis for Introducing IPv6 into ISP Networks
ISP网络引入IPv6的场景与分析
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified.
本文档描述了在不中断IPv4服务的情况下将IPv6引入ISP现有IPv4网络的不同场景。分析了引入IPv6的场景，并评估了已定义的转换机制的相关性。还确定了已知的挑战。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Goal and Scope of the Document. . . . . . . . . . . . . 2
2. Brief Description of a Generic ISP Network. . . . . . . . . . 3
3. Transition Scenarios. . . . . . . . . . . . . . . . . . . . . 4
3.1. Identification of Stages and Scenarios. . . . . . . . . 4
3.2. Stages. . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Stage 1 Scenarios: Launch . . . . . . . . . . . 5
3.2.2. Stage 2a Scenarios: Backbone. . . . . . . . . . 6
3.2.3. Stage 2b Scenarios: Customer Connection . . . . 6
3.2.4. Stage 3 Scenarios: Complete . . . . . . . . . . 7
3.2.5. Stages 2a and 3: Combination Scenarios. . . . . 7
3.3. Transition Scenarios. . . . . . . . . . . . . . . . . . 7
3.4. Actions Needed When Deploying IPv6 in an ISP's Network. 8
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Goal and Scope of the Document. . . . . . . . . . . . . 2
2. Brief Description of a Generic ISP Network. . . . . . . . . . 3
3. Transition Scenarios. . . . . . . . . . . . . . . . . . . . . 4
3.1. Identification of Stages and Scenarios. . . . . . . . . 4
3.2. Stages. . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Stage 1 Scenarios: Launch . . . . . . . . . . . 5
3.2.2. Stage 2a Scenarios: Backbone. . . . . . . . . . 6
3.2.3. Stage 2b Scenarios: Customer Connection . . . . 6
3.2.4. Stage 3 Scenarios: Complete . . . . . . . . . . 7
3.2.5. Stages 2a and 3: Combination Scenarios. . . . . 7
3.3. Transition Scenarios. . . . . . . . . . . . . . . . . . 7
3.4. Actions Needed When Deploying IPv6 in an ISP's Network. 8
4. Backbone Transition Actions . . . . . . . . . . . . . . . . . 9
4.1. Steps in the Transition of Backbone Networks. . . . . . 9
4.1.1. MPLS Backbone . . . . . . . . . . . . . . . . . 9
4.2. Configuration of Backbone Equipment . . . . . . . . . . 10
4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. EGP . . . . . . . . . . . . . . . . . . . . . . 12
4.3.3. Transport of Routing Protocols. . . . . . . . . 12
4.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . 13
5. Customer Connection Transition Actions. . . . . . . . . . . . 13
5.1. Steps in the Transition of Customer Connection Networks 13
5.1.1. Small End Sites . . . . . . . . . . . . . . . . 14
5.1.2. Large End Sites . . . . . . . . . . . . . . . . 15
5.2. User Authentication/Access Control Requirements . . . . 15
5.3. Configuration of Customer Equipment . . . . . . . . . . 16
5.4. Requirements for Traceability . . . . . . . . . . . . . 16
5.5. Ingress Filtering in the Customer Connection Network. . 17
5.6. Multihoming . . . . . . . . . . . . . . . . . . . . . . 17
5.7. Quality of Service. . . . . . . . . . . . . . . . . . . 17
6. Network and Service Operation Actions . . . . . . . . . . . . 18
7. Future Stages . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Requirements for Follow-On Work . . . . . . . . . . . . . . . 19
9. Example Networks. . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 22
9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. Informative References. . . . . . . . . . . . . . . . . . . . 24
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28
4. Backbone Transition Actions . . . . . . . . . . . . . . . . . 9
4.1. Steps in the Transition of Backbone Networks. . . . . . 9
4.1.1. MPLS Backbone . . . . . . . . . . . . . . . . . 9
4.2. Configuration of Backbone Equipment . . . . . . . . . . 10
4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. EGP . . . . . . . . . . . . . . . . . . . . . . 12
4.3.3. Transport of Routing Protocols. . . . . . . . . 12
4.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . 13
5. Customer Connection Transition Actions. . . . . . . . . . . . 13
5.1. Steps in the Transition of Customer Connection Networks 13
5.1.1. Small End Sites . . . . . . . . . . . . . . . . 14
5.1.2. Large End Sites . . . . . . . . . . . . . . . . 15
5.2. User Authentication/Access Control Requirements . . . . 15
5.3. Configuration of Customer Equipment . . . . . . . . . . 16
5.4. Requirements for Traceability . . . . . . . . . . . . . 16
5.5. Ingress Filtering in the Customer Connection Network. . 17
5.6. Multihoming . . . . . . . . . . . . . . . . . . . . . . 17
5.7. Quality of Service. . . . . . . . . . . . . . . . . . . 17
6. Network and Service Operation Actions . . . . . . . . . . . . 18
7. Future Stages . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Requirements for Follow-On Work . . . . . . . . . . . . . . . 19
9. Example Networks. . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 22
9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. Informative References. . . . . . . . . . . . . . . . . . . . 24
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28
When an ISP deploys IPv6, its goal is to provide IPv6 connectivity and global address space to its customers. The new IPv6 service must be added to an existing IPv4 service, and the introduction of IPv6 must not interrupt this IPv4 service.
ISP部署IPv6时，其目标是为其客户提供IPv6连接和全局地址空间。必须将新的IPv6服务添加到现有的IPv4服务中，并且IPv6的引入不得中断此IPv4服务。
An ISP offering IPv4 service will find different ways to add IPv6 to this service. This document discusses a small set of scenarios for the introduction of IPv6 into an ISP's IPv4 network. It evaluates the relevance of the existing transition mechanisms in the context of these deployment scenarios and points out the lack of essential functionality in these methods.
提供IPv4服务的ISP将找到不同的方法将IPv6添加到此服务。本文档讨论将IPv6引入ISP IPv4网络的一小部分场景。它评估了现有过渡机制在这些部署场景中的相关性，并指出这些方法中缺乏基本功能。
The document is focused on services that include both IPv6 and IPv4 and does not cover issues surrounding IPv6-only service. It is also outside the scope of this document to describe different types of access or network technologies.
本文档的重点是同时包含IPv6和IPv4的服务，而不涉及仅限IPv6服务的相关问题。描述不同类型的接入或网络技术也不在本文件的范围之内。
A generic network topology for an ISP can be divided into two main parts: the backbone network and customer connection networks. In addition, it includes building blocks such as network and service operations. The additional building blocks used in this document are defined as follows:
ISP的通用网络拓扑可分为两个主要部分：主干网和客户连接网。此外，它还包括构建模块，如网络和服务操作。本文件中使用的其他构建块定义如下：
"CPE" : Customer Premises Equipment
“CPE”：客户场所设备
"PE" : Provider Edge Equipment
“PE”：供应商边缘设备
"Network and service operation" : This is the part of the ISP's network that hosts the services required for the correct operation of the ISP's network. These services usually include management, supervision, accounting, billing, and customer management applications.
“网络和服务运行”：这是ISP网络的一部分，承载ISP网络正确运行所需的服务。这些服务通常包括管理、监督、会计、计费和客户管理应用程序。
"Customer connection" : This is the part of the network used by a customer when connecting to an ISP's network. It includes the CPE, the last hop link, and the parts of the PE interfacing to the last hop link.
“客户连接”：这是客户连接到ISP网络时使用的网络部分。它包括CPE、最后一跳链路，以及连接到最后一跳链路的PE部分。
"Backbone" : This is the rest of the ISP's network infrastructure. It includes the parts of the PE interfacing to the core, the core routers of the ISP, and the border routers used to exchange routing information with other ISPs (or other administrative entities).
“主干网”：这是ISP的其余网络基础设施。它包括连接到核心的PE部分、ISP的核心路由器以及用于与其他ISP（或其他管理实体）交换路由信息的边界路由器。
"Dual-stack network" : A network that natively supports both IPv4 and IPv6.
“双栈网络”：本机支持IPv4和IPv6的网络。
In some cases (e.g., incumbent national or regional operators), a given customer connection network may have to be shared between or among different ISPs. According to the type of customer connection network used (e.g., one involving only layer 2 devices or one involving non-IP technology), this constraint may result in architectural considerations relevant to this document.
在某些情况下（例如，现任国家或地区运营商），可能必须在不同ISP之间共享给定的客户连接网络。根据所使用的客户连接网络类型（例如，一个仅涉及第2层设备或一个涉及非IP技术），此约束可能导致与本文档相关的架构考虑。
The basic components in the ISP's network are depicted in Figure 1.
ISP网络中的基本组件如图1所示。
------------ ----------
| Network and| | |
| Service |--| Backbone |
| Operation | | |\
------------ ---------- \
/ | \ \
/ | \ \_Peering (Direct and
/ | \ exchange points)
/ | \
/ | \
---------- / ---------- \ ----------
| Customer | / | Customer | \ | Customer |
|Connection|--/ |Connection| \--|Connection|
| 1 | | 2 | | 3 |
---------- ---------- ----------
| | | ISP's Network
-------------------------------------------------------
| | | Customers' Networks
+--------+ +--------+ +--------+
| | | | | |
|Customer| |Customer| |Customer|
| | | | | |
+--------+ +--------+ +--------+
------------ ----------
| Network and| | |
| Service |--| Backbone |
| Operation | | |\
------------ ---------- \
/ | \ \
/ | \ \_Peering (Direct and
/ | \ exchange points)
/ | \
/ | \
---------- / ---------- \ ----------
| Customer | / | Customer | \ | Customer |
|Connection|--/ |Connection| \--|Connection|
| 1 | | 2 | | 3 |
---------- ---------- ----------
| | | ISP's Network
-------------------------------------------------------
| | | Customers' Networks
+--------+ +--------+ +--------+
| | | | | |
|Customer| |Customer| |Customer|
| | | | | |
+--------+ +--------+ +--------+
Figure 1: ISP Network Topology
图1:ISP网络拓扑
This section describes different stages an ISP might consider when introducing IPv6 connectivity into its existing IPv4 network and the different scenarios of what might occur in the respective stages.
本节描述了在将IPv6连接引入其现有IPv4网络和不同阶段可能发生的不同场景时，ISP可能会考虑的不同阶段。
The stages here are snapshots of the ISP's network with respect to IPv6 maturity. Because the ISP's network is continually evolving, a stage is a measure of how far along the ISP has come in terms of implementing the functionality necessary to offer IPv6 to its customers.
这里的阶段是关于IPv6成熟度的ISP网络快照。由于ISP的网络在不断发展，因此阶段是衡量ISP在实现向其客户提供IPv6所需功能方面取得了多大进展的尺度。
It is possible for a transition to occur freely between different stages. Although a network segment can only be in one stage at a time, the ISP's network as a whole can be in different stages. Different transition paths can be followed from the first to the final stage. The transition between two stages does not have to be instantaneous; it can occur gradually.
在不同阶段之间可以自由地进行过渡。虽然一个网段一次只能处于一个阶段，但ISP的整个网络可以处于不同的阶段。从第一阶段到最后阶段，可以遵循不同的过渡路径。两个阶段之间的过渡不一定是瞬时的；它可以逐渐发生。
Each stage has different IPv6 properties. Therefore, based on its requirements, an ISP can decide which set of stages it will follow and in what order to transform its network.
每个阶段都有不同的IPv6属性。因此，ISP可以根据其要求决定将遵循哪一组阶段以及以何种顺序改造其网络。
This document is not aimed at covering small ISPs, hosting providers, or data centers; only the scenarios applicable to ISPs eligible for at least a /32 IPv6 prefix allocation from an RIR are covered.
本文件不针对小型ISP、托管提供商或数据中心；仅涵盖适用于符合RIR至少分配a/32 IPv6前缀条件的ISP的场景。
The stages are derived from the generic description of an ISP's network in Section 2. Combinations of different building blocks that constitute an ISP's environment lead to a number of scenarios from which the ISP can choose. The scenarios most relevant to this document are those that maximize an ISP's ability to offer IPv6 to its customers in the most efficient and feasible way. The assumption in all stages is that the ISP's goal is to offer both IPv4 and IPv6 to the customer.
这些阶段源自第2节中对ISP网络的一般描述。构成ISP环境的不同构建块的组合导致了ISP可以选择的许多场景。与本文档最相关的场景是那些使ISP能够以最有效和可行的方式向其客户提供IPv6的场景。所有阶段的假设都是ISP的目标是向客户提供IPv4和IPv6。
The four most probable stages are as follows:
四个最可能的阶段如下：
o Stage 1 Launch o Stage 2a Backbone o Stage 2b Customer connection o Stage 3 Complete
o 第1阶段启动o第2a阶段主干o第2b阶段客户连接o第3阶段完成
Generally, an ISP is able to upgrade a current IPv4 network to an IPv4/IPv6 dual-stack network via Stage 2b, but the IPv6 service can also be implemented at a small cost by adding simple tunnel mechanisms to the existing configuration. When a new network is designed, Stage 3 might be the first or last step because there are no legacy concerns. Nevertheless, the absence of IPv6 capability in the network equipment can still be a limiting factor.
通常，ISP能够通过阶段2b将当前IPv4网络升级为IPv4/IPv6双栈网络，但也可以通过在现有配置中添加简单的隧道机制以较小的成本实现IPv6服务。设计新网络时，阶段3可能是第一步或最后一步，因为没有遗留问题。然而，网络设备中缺乏IPv6能力仍然是一个限制因素。
Note that in every stage except Stage 1, the ISP can offer both IPv4 and IPv6 services to its customers.
请注意，在除第1阶段外的每个阶段，ISP都可以向其客户提供IPv4和IPv6服务。
The first stage is an IPv4-only ISP with an IPv4 customer. This is the most common case today and is the natural starting point for the introduction of IPv6. From this stage, the ISP can move (undergo a transition) from Stage 1 to any other stage with the goal of offering IPv6 to its customer.
第一阶段是一个只有IPv4的ISP和一个IPv4客户。这是当今最常见的情况，也是引入IPv6的自然起点。从这个阶段开始，ISP可以从第1阶段过渡到任何其他阶段，目标是向其客户提供IPv6。
The immediate first step consists of obtaining a prefix allocation (typically a /32) from the appropriate RIR (e.g., AfriNIC, APNIC, ARIN, LACNIC, RIPE) according to allocation procedures.
第一步包括根据分配程序从适当的RIR（例如AfriNIC、APNIC、ARIN、LACNIC、RIME）获得前缀分配（通常为a/32）。
The ISP will also need to establish IPv6 connectivity to its upstream providers and peers; it is of utmost importance to require IPv6 transit when negotiating IP transit deals with the upstream ISPs. If the upstream is not providing IPv6 connectivity at the moment, it may be possible to obtain temporary connectivity from a nearby ISP, possibly using a short configured tunnel. However, the longer-term goal must be to require and to obtain IPv6 connectivity from the transit ISPs, because otherwise the quality of IPv6 connectivity will likely be poor.
ISP还需要与其上游提供商和对等方建立IPv6连接；在与上游ISP协商IP传输协议时，要求IPv6传输至关重要。如果上游目前不提供IPv6连接，则可以从附近的ISP获得临时连接，可能使用配置的短隧道。然而，长期目标必须是要求并获得中转ISP的IPv6连接，因为否则IPv6连接的质量可能会很差。
Connectivity to peers can typically be established either directly or at Internet Exchange Points (IX). Most IXs use techniques where IPv6 is easy to use, and many IXs already provide infrastructure for IPv6 peerings. Such peerings can be done natively by using IPv6. Peerings over IPv6-in-IPv4 tunnels is also possible but not recommended, at least in the long term. Direct connectivity to peers may be feasible when there is direct connectivity to the peer for IPv4.
通常可以直接或在Internet交换点（IX）建立与对等方的连接。大多数IX使用IPv6易于使用的技术，许多IX已经为IPv6对等提供了基础设施。这样的对等可以通过使用IPv6以本机方式完成。IPv6-in-IPv4隧道上的对等也是可能的，但至少从长远来看，不建议这样做。当IPv4直接连接到对等方时，直接连接到对等方可能是可行的。
Stage 2a deals with an ISP with IPv4-only customer connection networks and a backbone that supports both IPv4 and IPv6. In particular, the ISP has the possibility of making the backbone IPv6- capable through software upgrades, hardware upgrades, or a combination of both.
阶段2a涉及具有仅IPv4客户连接网络和同时支持IPv4和IPv6的主干网的ISP。特别是，ISP有可能通过软件升级、硬件升级或两者的结合使主干网支持IPv6。
Since the customer connections have not yet been upgraded, a tunneling mechanism has to be used to provide IPv6 connectivity through the IPv4 customer connection networks. The customer can terminate the tunnel at the CPE (if it has IPv6 support) or at some set of devices internal to its network. That is, either the CPE or a device inside the network could provide global IPv6 connectivity to the rest of the devices in the customer's network.
由于客户连接尚未升级，因此必须使用隧道机制通过IPv4客户连接网络提供IPv6连接。客户可以在CPE（如果支持IPv6）或其网络内部的某组设备上终止隧道。也就是说，CPE或网络内的设备都可以向客户网络中的其余设备提供全局IPv6连接。
Stage 2b consists of an ISP with an IPv4 backbone network and a customer connection network that supports both IPv4 and IPv6. Because the service to the customer is native IPv6, the customer is not required to support both IPv4 and IPv6. This is the biggest difference from the previous stage. The need to exchange IPv6 traffic still exists but might be more complicated than in the previous case because the backbone is not IPv6-enabled. After completing Stage 2b, the original IPv4 backbone is unchanged. This means that the IPv6 traffic is transported either by tunneling over the existing IPv4 backbone, or in an IPv6 overlay network more or less separated from the IPv4 backbone.
阶段2b包括一个具有IPv4骨干网络的ISP和一个同时支持IPv4和IPv6的客户连接网络。因为客户的服务是本机IPv6，所以客户不需要同时支持IPv4和IPv6。这是与前一阶段最大的区别。交换IPv6流量的需求仍然存在，但可能比前一种情况更复杂，因为主干网未启用IPv6。在完成阶段2b之后，原始IPv4主干保持不变。这意味着IPv6流量可以通过现有IPv4主干上的隧道传输，也可以在与IPv4主干或多或少分离的IPv6覆盖网络中传输。
Normally, the ISP will continue to provide IPv4 connectivity by using private (NATted by the ISP) or public IPv4 address. In many cases, the customer also has a NAT of his/her own; if so, this likely continues to be used for IPv4 connectivity.
通常，ISP将继续使用专用（由ISP指定）或公用IPv4地址提供IPv4连接。在许多情况下，客户也有自己的NAT；如果是这样，这可能会继续用于IPv4连接。
Stage 3 could be considered the final step in introducing IPv6, at least within the scope of this document. This stage consists of ubiquitous IPv6 service with native support for IPv6 and IPv4 in both backbone and customer connection networks. From the customer's perspective, it is identical to the previous stage because the customer connection network has not changed. The requirement for exchanging IPv6 traffic is identical to that of Stage 2.
第3阶段可以被视为引入IPv6的最后一步，至少在本文件的范围内。此阶段包括无处不在的IPv6服务，在主干网和客户连接网络中都支持IPv6和IPv4。从客户的角度来看，这与前一阶段相同，因为客户连接网络没有改变。交换IPv6流量的要求与第2阶段的要求相同。
Some ISPs may use different access technologies of varying IPv6 maturity. This may result in a combination of the Stages 2a and 3: some customer connections do not support IPv6, but others do; in both cases the backbone is dual-stack.
一些ISP可能使用不同IPv6成熟度的不同接入技术。这可能导致阶段2a和阶段3的组合：一些客户连接不支持IPv6，但其他客户连接支持IPv6；在这两种情况下，主干都是双堆栈。
This scenario is equivalent to Stage 2a, but it requires support for native IPv6 customer connections on some access technologies.
此场景相当于第2a阶段，但它需要在某些访问技术上支持本机IPv6客户连接。
Given the different stages, it is clear that an ISP has to be able to make a transition from one stage to another. The initial stage in this document is an IPv4-only service and network. The end stage is a dual IPv4/IPv6 service and network.
考虑到不同的阶段，ISP显然必须能够从一个阶段过渡到另一个阶段。本文档的初始阶段是仅IPv4服务和网络。最终阶段是一个双IPv4/IPv6服务和网络。
The transition starts with an IPv4 ISP and then moves in one of three directions. This choice corresponds to the different transition scenarios. Stage 2a consists of upgrading the backbone first. Stage 2b consists of upgrading the customer connection network. Finally, Stage 3 consists of introducing IPv6 in both the backbone and customer connections as needed.
转换从IPv4 ISP开始，然后向三个方向之一移动。此选项对应于不同的过渡场景。第2a阶段包括首先升级主干网。阶段2b包括升级客户连接网络。最后，第3阶段包括根据需要在主干网和客户连接中引入IPv6。
Because most ISP backbone IPv4 networks continually evolve (firmware replacements in routers, new routers, etc.), they can be made ready for IPv6 without additional investment (except staff training). This transition path may be slower but still useful, as it allows for the introduction of IPv6 without any actual customer demand. This approach may be superior to doing everything at the last minute, which may entail a higher investment. However, it is important to consider (and to request from vendors) IPv6 features in all new equipment from the outset. Otherwise, the time and effort required
由于大多数ISP骨干IPv4网络不断发展（路由器中的固件更换、新路由器等），因此无需额外投资（员工培训除外），就可以为IPv6做好准备。这种过渡路径可能较慢，但仍然有用，因为它允许在没有任何实际客户需求的情况下引入IPv6。这种方法可能比在最后一刻做任何事情都要好，因为这可能需要更高的投资。然而，重要的是从一开始就考虑（以及向供应商请求）所有新设备中的IPv6特征。否则，所需的时间和精力
to remove non-IPv6-capable hardware from the network may be significant.
从网络中删除不支持IPv6的硬件可能非常重要。
Examination of the transitions described above reveals that it is possible to split the work required for each transition into a small set of actions. Each action is largely independent of the others, and some actions may be common to multiple transitions.
对上述转换的检查表明，可以将每个转换所需的工作划分为一组小的操作。每个动作在很大程度上独立于其他动作，有些动作可能是多个转换的共同动作。
Analysis of the possible transitions leads to a small list of actions:
对可能的转换进行分析，得出一小部分操作：
* Actions required for backbone transition:
* 主干网转换所需的操作：
- Connect dual-stack customer connection networks to other IPv6 networks through an IPv4 backbone.
- 通过IPv4主干将双栈客户连接网络连接到其他IPv6网络。
- Transform an IPv4 backbone into a dual-stack one. This action can be performed directly or through intermediate steps.
- 将IPv4主干转换为双堆栈主干。此操作可以直接执行，也可以通过中间步骤执行。
* Actions required for customer connection transition:
* 客户连接转换所需的操作：
- Connect IPv6 customers to an IPv6 backbone through an IPv4 network.
- 通过IPv4网络将IPv6客户连接到IPv6主干网。
- Transform an IPv4 customer connection network into a dual-stack one.
- 将IPv4客户连接网络转换为双堆栈网络。
* Actions required for network and service operation transition:
* 网络和服务运营过渡所需的措施：
- Set up IPv6 connectivity to upstream providers and peers.
- 设置到上游提供商和对等方的IPv6连接。
- Configure IPv6 functions into network components.
- 将IPv6功能配置到网络组件中。
- Upgrade regular network management and monitoring applications to take IPv6 into account.
- 升级常规网络管理和监视应用程序以考虑IPv6。
- Extend customer management (e.g., RADIUS) mechanisms to be able to supply IPv6 prefixes and other information to customers.
- 扩展客户管理（例如RADIUS）机制，以便能够向客户提供IPv6前缀和其他信息。
- Enhance accounting, billing, and so on to work with IPv6 as needed. (Note: If dual-stack service is offered, this may not be necessary.)
- 增强记帐、计费等功能，以便根据需要使用IPv6。（注意：如果提供双堆栈服务，则可能不需要这样做。）
- Implement security for network and service operation.
- 实施网络和服务操作的安全性。
Sections 4, 5, and 6 contain detailed descriptions of each action.
第4节、第5节和第6节详细描述了每个动作。
In terms of physical equipment, backbone networks mainly consist of high-speed core and edge routers. Border routers provide peering with other providers. Filtering, routing policy, and policing functions are generally managed on border routers.
在物理设备方面，骨干网主要由高速核心路由器和边缘路由器组成。边界路由器提供与其他提供商的对等。过滤、路由策略和策略功能通常在边界路由器上进行管理。
In the beginning, an ISP has an IPv4-only backbone. In the end, the backbone is completely dual-stack. In between, intermediate steps may be identified:
一开始，ISP只有IPv4主干网。最后，主干是完全双栈的。在这两者之间，可以确定中间步骤：
Tunnels Tunnels Dual Full
IPv4-only ----> or ---> or + Stack --> Dual Stack
dedicated IPv6 dedicated IPv6 routers
links links
Tunnels Tunnels Dual Full
IPv4-only ----> or ---> or + Stack --> Dual Stack
dedicated IPv6 dedicated IPv6 routers
links links
Figure 2: Transition Path
图2：转换路径
The first step involves tunnels or dedicated links but leaves existing routers unchanged. Only a small set of routers then have IPv6 capabilities. The use of configured tunnels is adequate during this step.
第一步涉及隧道或专用链路，但保持现有路由器不变。只有一小部分路由器具有IPv6功能。在此步骤中，使用配置的隧道是足够的。
In the second step, some dual-stack routers are added, progressively, to this network.
在第二步中，一些双栈路由器逐渐添加到该网络中。
The final step is reached when all or almost all routers are dual-stack.
当所有或几乎所有路由器都是双栈时，就达到了最后一步。
For many reasons (technical, financial, etc.), the ISP may progress step by step or jump directly to the final one. One important criterion in planning this evolution is the number of IPv6 customers the ISP expects during its initial deployments. If few customers connect to the original IPv6 infrastructure, then the ISP is likely to remain in the initial steps for a long time.
出于许多原因（技术、财务等），ISP可能会一步一步地前进，或者直接跳到最后一步。规划这一演进的一个重要标准是ISP在初始部署期间预期的IPv6客户数量。如果很少有客户连接到最初的IPv6基础设施，那么ISP可能会在很长一段时间内停留在最初的步骤中。
In short, each intermediate step is possible, but none is mandatory.
简而言之，每个中间步骤都是可能的，但没有一个是强制性的。
If MPLS is already deployed in the backbone, it may be desirable to provide IPv6-over-MPLS connectivity. However, setting up an IPv6 Label Switched Path (LSP) requires signaling through the MPLS
如果MPLS已经部署在主干网中，则可能需要通过MPLS提供IPv6连接。但是，设置IPv6标签交换路径（LSP）需要通过MPLS发送信令
network; both LDP and RSVP-TE can set up IPv6 LSPs, but this might require upgrade/change in the MPLS core network.
网络LDP和RSVP-TE都可以设置IPv6 LSP，但这可能需要升级/更改MPLS核心网络。
An alternative approach is to use BGP for signaling or to perform; for example, IPv6-over-IPv4/MPLS, as described in [BGPTUNNEL]. Some possibilities are preferable to others, depending on the specific environment under consideration. The approaches seem to be as follows:
另一种方法是使用BGP发信号或执行；例如，IPv6-over-IPv4/MPLS，如[BGPTUNNEL]中所述。根据所考虑的具体环境，某些可能性比其他可能性更可取。这些方法似乎如下：
1) Require that MPLS networks deploy native IPv6 routing and forwarding support.
1) 要求MPLS网络部署本机IPv6路由和转发支持。
2) Require that MPLS networks support native routing and setting up of IPv6 LSPs, used for IPv6 connectivity.
2) 要求MPLS网络支持用于IPv6连接的IPv6 LSP的本机路由和设置。
3) Use only configured tunneling over IPv4 LSPs.
3) 仅使用通过IPv4 LSP配置的隧道。
4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation for IPv6 connectivity.
4) 使用[BGPTUNNEL]为IPv6连接执行IPv6-over-IPv4/MPLS封装。
Approaches 1) and 2) are clearly the best target approaches. However, approach 1) may not be possible if the ISP is not willing to add IPv6 support in the network, or if the installed equipment is not capable of high performance native IPv6 forwarding. Approach 2) may not be possible if the ISP is unwilling or unable to add IPv6 LSP set-up support in the MPLS control plane.
方法1）和2）显然是最好的目标方法。但是，如果ISP不愿意在网络中添加IPv6支持，或者如果安装的设备无法进行高性能本机IPv6转发，则方法1）可能不可能。如果ISP不愿意或无法在MPLS控制平面中添加IPv6 LSP设置支持，则方法2）可能不可能。
Approach 4) can be used as an interim mechanism when other options are unfeasible or undesirable for the reasons discussed above.
如果由于上述原因，其他选择不可行或不可取，可将方法4）用作临时机制。
Approach 3) is roughly equivalent to approach 4) except that it does not require additional mechanisms but may lack scalability in the larger networks, especially if IPv6 is widely deployed.
方法3）大致等同于方法4），只是它不需要额外的机制，但在更大的网络中可能缺乏可扩展性，特别是在广泛部署IPv6的情况下。
In the backbone, the number of devices is small, and IPv6 configuration mainly deals with routing protocol parameters, interface addresses, loop-back addresses, access control lists, and so on.
在主干网中，设备数量较少，IPv6配置主要处理路由协议参数、接口地址、环回地址、访问控制列表等。
These IPv6 parameters need to be configured manually.
需要手动配置这些IPv6参数。
ISPs need routing protocols to advertise reachability and to find the shortest working paths, both internally and externally.
ISP需要路由协议来宣传可达性，并在内部和外部找到最短的工作路径。
Either OSPFv2 or IS-IS is typically used as the IPv4 IGP. RIPv2 is not usually used in service provider networks, as OSPF and IS-IS are superior IGPs. BGP is the only IPv4 EGP. Static routes also are used in both cases.
OSPFv2或IS-IS通常用作IPv4 IGP。RIPv2通常不用于服务提供商网络，因为OSPF和is-is是高级IGP。BGP是唯一的IPv4 EGP。在这两种情况下也使用静态路由。
Note that it is possible to configure a given network so that it has an IPv6 topology different from its IPv4 topology. For example, some links or interfaces may be dedicated to IPv4-only or IPv6-only traffic, or some routers may be dual-stack whereas others may be IPv4- or IPv6-only. In this case, routing protocols must be able to understand and cope with multiple topologies.
请注意，可以配置给定网络，使其具有与其IPv4拓扑不同的IPv6拓扑。例如，一些链路或接口可能专用于仅IPv4或仅IPv6的流量，或者一些路由器可能是双栈的，而其他路由器可能是仅IPv4或IPv6的。在这种情况下，路由协议必须能够理解和处理多种拓扑。
Once the IPv6 topology has been determined, the choice of IPv6 IGP must be made: either OSPFv3 or IS-IS for IPv6. RIPng is not appropriate in most contexts, due to RIPv2 not being appropriate for IPv4 either, and is therefore not discussed here. The IGP typically includes the routers' point-to-point and loop-back addresses.
一旦确定了IPv6拓扑，就必须选择IPv6 IGP：对于IPv6，选择OSPFv3或IS-IS。RIPng在大多数情况下都不合适，因为RIPv2也不适合IPv4，因此这里不讨论。IGP通常包括路由器的点对点和环回地址。
The most important decision is whether one wishes to have separate routing protocol processes for IPv4 and IPv6. Separating them requires more memory and CPU for route calculations, e.g., when the links flap. But separation provides a measure of assurance that should problems arise with IPv6 routing, they will not affect the IPv4 routing protocol. In the initial phases, if it is uncertain whether joint IPv4-IPv6 networking is working as intended, running separate processes may be desirable and easier to manage.
最重要的决定是是否希望IPv4和IPv6有单独的路由协议进程。分离它们需要更多的内存和CPU来进行路由计算，例如，当链路摆动时。但是分离提供了一种保证措施，如果IPv6路由出现问题，它们将不会影响IPv4路由协议。在初始阶段，如果不确定IPv4-IPv6联合网络是否按预期工作，则可能需要运行单独的进程，并且更易于管理。
The possible combinations are as follows:
可能的组合如下：
- With separate processes: o OSPFv2 for IPv4, IS-IS for IPv6 (only) o OSPFv2 for IPv4, OSPFv3 for IPv6, or o IS-IS for IPv4, OSPFv3 for IPv6
- 使用单独的进程：o OSPFv2用于IPv4，IS-IS（仅限IPv6）o OSPFv2用于IPv4，OSPFv3用于IPv6，或o IS-IS用于IPv4，OSPFv3用于IPv6
- With the same process: o IS-IS for both IPv4 and IPv6
- 使用相同的过程：IPv4和IPv6都是o-IS-IS
Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6 topologies must be "convex", unless the multiple-topology IS-IS extensions [MTISIS] have been implemented (using IS-IS for only IPv4 or only IPv6 requires no convexity). In simpler networks or with careful planning of IS-IS link costs, it is possible to keep even incongruent IPv4/IPv6 topologies "convex". The convexity problem is explained in more detail with an example in Appendix A.
请注意，如果IS-IS同时用于IPv4和IPv6，则IPv4/IPv6拓扑必须是“凸型”的，除非已实现多个拓扑IS-IS扩展[MTISIS]（仅将IS-IS用于IPv4或仅用于IPv6不需要凸型）。在更简单的网络中，或者在仔细规划IS-IS链路成本的情况下，甚至可以使不一致的IPv4/IPv6拓扑保持“凸性”。附录A中的示例更详细地解释了凸性问题。
When deploying full dual-stack in the short-term, using single-topology IS-IS is recommended. This may be particularly applicable for some larger ISPs. In other scenarios, choosing between one or two separate processes often depends on the perceived risk to the IPv4 routing infrastructure, i.e., whether one wishes to keep them separate for the time being. If this is not a factor, using a single process is usually preferable for operational reasons: not having to manage two protocols and topologies.
在短期内部署完整的双堆栈时，建议使用单拓扑IS-IS。这可能特别适用于一些较大的ISP。在其他场景中，在一个或两个单独的进程之间进行选择通常取决于对IPv4路由基础设施的感知风险，即，是否希望暂时将它们分开。如果这不是一个因素，出于操作原因，通常最好使用单个进程：不必管理两个协议和拓扑。
The IGP is typically only used to carry loopback and point-to-point addresses and doesn't include customer prefixes or external routes. Internal BGP (iBGP), as described in the next section, is most often deployed in all routers (PE and core) to distribute routing information about customer prefixes and external routes.
IGP通常仅用于承载环回和点到点地址，不包括客户前缀或外部路由。如下一节所述，内部BGP（iBGP）通常部署在所有路由器（PE和core）中，以分发有关客户前缀和外部路由的路由信息。
Some of the simplest devices (e.g., CPE routers) may not implement routing protocols other than RIPng. In some cases, therefore, it may be necessary to run RIPng in addition to one of the above IGPs, at least in a limited fashion, and then, by some mechanism, to redistribute routing information between the routing protocols.
一些最简单的设备（例如，CPE路由器）可能无法实现RIPng以外的路由协议。因此，在某些情况下，可能需要至少以有限的方式在上述igp之一之外运行RIPng，然后通过某种机制在路由协议之间重新分配路由信息。
BGP is used for both internal and external BGP sessions.
BGP用于内部和外部BGP会话。
BGP with multiprotocol extensions [RFC2858] can be used for IPv6 [RFC2545]. These extensions enable the exchange of IPv6 routing information and the establishment of BGP sessions using TCP over IPv6.
带有多协议扩展[RFC2858]的BGP可用于IPv6[RFC2545]。这些扩展支持通过IPv6上的TCP交换IPv6路由信息和建立BGP会话。
It is possible to use a single BGP session to advertise both IPv4 and IPv6 prefixes between two peers. However, the most common practice today is to use separate BGP sessions.
可以使用单个BGP会话在两个对等方之间播发IPv4和IPv6前缀。然而，目前最常见的做法是使用单独的BGP会话。
IPv4 routing information should be carried by IPv4 transport and, similarly, IPv6 routing information by IPv6 for several reasons:
IPv4路由信息应由IPv4传输承载，同样，IPv6路由信息应由IPv6承载，原因如下：
* IPv6 connectivity may work when IPv4 connectivity is down (or vice-versa). * The best route for IPv4 is not always the best one for IPv6.
* IPv6连接可能在IPv4连接关闭时工作（反之亦然）。*IPv4的最佳路由并不总是IPv6的最佳路由。
* The IPv4 and IPv6 logical topologies may be different because the administrator may want to assign different metrics to a physical link for load balancing or because tunnels may be in use.
* IPv4和IPv6逻辑拓扑可能不同，因为管理员可能希望为物理链路分配不同的度量以实现负载平衡，或者因为可能正在使用隧道。
Currently, IPv6 multicast is not a major concern for most ISPs. However, some of them are considering deploying it. Multicast is achieved by using the PIM-SM and PIM-SSM protocols. These also work with IPv6.
目前，IPv6多播并不是大多数ISP主要关注的问题。然而，他们中的一些人正在考虑部署它。多播是通过使用PIM-SM和PIM-SSM协议实现的。这些也适用于IPv6。
Information about multicast sources is exchanged by using MSDP in IPv4, but MSDP is intentionally not defined for IPv6. Instead, one should use only PIM-SSM or an alternative mechanism for conveying the information [EMBEDRP].
在IPv4中使用MSDP交换有关多播源的信息，但有意不为IPv6定义MSDP。相反，应仅使用PIM-SSM或用于传输信息的替代机制[EMBEDRP]。
Customer connection networks are generally composed of a small set of PEs connected to a large set of CPEs and may be based on different technologies depending on the customer type or size, as well as the required bandwidth or even quality of service. Small unmanaged connection networks used for public customers usually rely on different technologies (e.g., dial-up or DSL) than the ones used for large customers, which typically run managed networks. Transitioning these infrastructures to IPv6 can be accomplished in several steps, but some ISPs, depending on their perception of the risks, may avoid some of the steps.
客户连接网络通常由连接到一组大型CPE的一组小型PE组成，并且可能基于不同的技术，具体取决于客户类型或规模，以及所需的带宽甚至服务质量。公共客户使用的小型非托管连接网络通常依赖于不同于大型客户使用的技术（例如拨号或DSL），大型客户通常运行托管网络。将这些基础设施过渡到IPv6可以通过几个步骤来完成，但是一些ISP可能会避免某些步骤，这取决于他们对风险的感知。
Connecting IPv6 customers to an IPv6 backbone through an IPv4 network can be considered a first careful step taken by an ISP to provide IPv6 services to its IPv4 customers. Some ISPs may also choose to provide IPv6 service independently from the regular IPv4 service.
通过IPv4网络将IPv6客户连接到IPv6主干可以被认为是ISP为其IPv4客户提供IPv6服务的第一步。一些ISP也可能选择独立于常规IPv4服务提供IPv6服务。
In any case, IPv6 service can be provided by using tunneling techniques. The tunnel may terminate at the CPE corresponding to the IPv4 service or in some other part of the customer's infrastructure (for instance, on IPv6-specific CPE or even on a host).
在任何情况下，都可以使用隧道技术提供IPv6服务。隧道可以在与IPv4服务相对应的CPE处终止，或者在客户基础设施的某些其他部分终止（例如，在特定于IPv6的CPE上，甚至在主机上）。
Several tunneling techniques have already been defined: configured tunnels with tunnel broker, 6to4 [RFC3056], Teredo [TEREDO], and so on. Some of these are based on a specific addressing plan independent of the ISP's allocated prefix(es), while others use a part of the ISP's prefix. In most cases, using the ISP's address space is preferable.
已经定义了几种隧道技术：使用隧道代理、6to4[RFC3056]、Teredo[Teredo]等配置隧道。其中一些基于独立于ISP分配的前缀的特定寻址计划，而另一些则使用ISP前缀的一部分。在大多数情况下，最好使用ISP的地址空间。
A key factor is the presence or absence of NATs between the two tunnel end-points. In most cases, 6to4 and ISATAP are incompatible with NATs, and UDP encapsulation for configured tunnels has not been specified.
一个关键因素是两个隧道端点之间是否存在NAT。在大多数情况下，6to4和ISATAP与NAT不兼容，并且尚未指定已配置隧道的UDP封装。
Dynamic and non-permanent IPv4 address allocation is another factor a tunneling technique may have to deal with. In this case, the tunneling techniques may be more difficult to deploy at the ISP's end, especially if a protocol including authentication (like PPP for IPv6) is not used. This may need to be considered in more detail.
动态和非永久IPv4地址分配是隧道技术可能必须处理的另一个因素。在这种情况下，隧道技术可能更难在ISP端部署，特别是在未使用包括身份验证的协议（如IPv6的PPP）的情况下。这可能需要更详细地考虑。
However, NAT traversal can be avoided if the NAT supports forwarding protocol-41 [PROTO41] and is configured to do so.
然而，如果NAT支持转发协议-41[PROTO41]并且被配置为这样做，则可以避免NAT遍历。
Firewalls in the path can also break tunnels of these types. The administrator of the firewall needs to create a hole for the tunnel. This is usually manageable, as long as the firewall is controlled by either the customer or the ISP, which is almost always the case.
路径中的防火墙也可以破坏这些类型的隧道。防火墙管理员需要为隧道创建一个洞。这通常是可管理的，只要防火墙由客户或ISP控制，几乎总是这样。
When the CPE is performing NAT or firewall functions, terminating the tunnels directly at the CPE typically simplifies the scenario considerably, avoiding the NAT and firewall traversal. If such an approach is adopted, the CPE has to support the tunneling mechanism used, or be upgraded to do so.
当CPE执行NAT或防火墙功能时，直接在CPE处终止隧道通常会大大简化场景，避免NAT和防火墙穿越。如果采用这种方法，则CPE必须支持所使用的隧道机制，或升级以支持该机制。
Tunneling considerations for small end sites are discussed in [UNMANEVA]. These identify solutions relevant to the first category of unmanaged networks. The tunneling requirements applicable in these scenarios are described in [TUNREQS].
[UNMANEVA]中讨论了小型终端站点的隧道注意事项。这些解决方案确定了与第一类非托管网络相关的解决方案。[TUNREQS]中描述了适用于这些场景的隧道要求。
The connectivity mechanisms can be categorized as "managed" or "opportunistic". The former consist of native service or a configured tunnel (with or without a tunnel broker); the latter include 6to4 and, e.g., Teredo -- they provide "short-cuts" between nodes using the same mechanisms and are available without contracts with the ISP.
连接机制可分为“管理”或“机会主义”。前者包括本机服务或配置的隧道（有或没有隧道代理）；后者包括6to4和Teredo——它们使用相同的机制在节点之间提供“捷径”，并且不需要与ISP签订合同。
The ISP may offer opportunistic services, mainly a 6to4 relay, especially as a test when no actual service is offered yet. At the later phases, ISPs might also deploy 6to4 relays and Teredo servers (or similar) to optimize their customers' connectivity to 6to4 and Teredo nodes.
ISP可能提供机会主义服务，主要是6to4中继，尤其是在尚未提供实际服务的情况下作为测试。在后期阶段，ISP还可能部署6to4中继和Teredo服务器（或类似服务器），以优化客户与6to4和Teredo节点的连接。
Opportunistic services are typically based on techniques that don't use IPv6 addresses from the ISP's allocated prefix(es), and the services have very limited functions to control the origin and the number of customers connected to a given relay.
机会主义服务通常基于不使用ISP分配的前缀中的IPv6地址的技术，并且这些服务在控制来源和连接到给定中继的客户数量方面的功能非常有限。
Most interesting are the managed services. When dual-stack is not an option, a form of tunneling must be used. When configured tunneling is not an option (e.g., due to dynamic IPv4 addressing), some form of
最有趣的是托管服务。如果不选择双堆栈，则必须使用隧道形式。当配置的隧道不是一个选项时（例如，由于动态IPv4寻址），某些形式的
automation has to be used. Basically, the options are either to deploy an L2TP architecture (whereby the customers would run L2TP clients and PPP over it to initiate IPv6 sessions) or to deploy a tunnel configuration service. The prime candidates for tunnel configuration are STEP [STEP] and TSP [TSP], which both also work in the presence of NATs. Neither is analyzed further in this document.
必须使用自动化。基本上，可以选择部署L2TP体系结构（客户可以通过该体系结构运行L2TP客户端和PPP来启动IPv6会话）或部署隧道配置服务。隧道配置的主要候选者是步骤[STEP]和TSP[TSP]，这两种方法也适用于NAT。本文件将进一步分析这两种情况。
Large end sites usually have a managed network.
大型终端站点通常有一个受管理的网络。
Dual-stack access service is often a possibility, as the customer network is managed (although CPE upgrades may be necessary).
由于客户网络得到管理（尽管可能需要CPE升级），因此双堆栈访问服务通常是可能的。
Configured tunnels, as-is, are a good solution when a NAT is not in the way and the IPv4 end-point addresses are static. In this scenario, NAT traversal is not typically required. If fine-grained access control is needed, an authentication protocol needs to be implemented.
当NAT不起作用且IPv4端点地址是静态的时，按现状配置的隧道是一个很好的解决方案。在这种情况下，通常不需要NAT遍历。如果需要细粒度的访问控制，则需要实现身份验证协议。
Tunnel brokering solutions have been proposed to help facilitate the set-up of a bi-directional tunnel. Such mechanisms are typically unnecessary for large end-sites, as simple configured tunneling or native access can be used instead. However, if such mechanisms would already be deployed, large sites starting to deploy IPv6 might benefit from them in any case.
已提出隧道经纪解决方案，以协助建立双向隧道。这种机制对于大型终端站点通常是不必要的，因为可以使用简单配置的隧道或本机访问。然而，如果已经部署了这样的机制，那么开始部署IPv6的大型站点在任何情况下都可能从中受益。
Teredo is not applicable in this scenario, as it can only provide IPv6 connectivity to a single host, not the whole site. 6to4 is not recommended due to its reliance on the relays and provider-independent address space, which makes it impossible to guarantee the required service quality and manageability large sites typically want.
Teredo不适用于此场景，因为它只能提供到单个主机的IPv6连接，而不是整个站点。由于6to4依赖于中继和独立于提供商的地址空间，因此不推荐使用6to4，这使得它无法保证大型站点通常需要的所需服务质量和可管理性。
User authentication can be used to control who can use the IPv6 connectivity service in the first place or who can access specific IPv6 services (e.g., NNTP servers meant for customers only). The former is described at more length below. The latter can be achieved by ensuring that for all the service-specific IPv4 access lists, there are also equivalent IPv6 access lists.
用户身份验证可用于控制谁可以首先使用IPv6连接服务，或者谁可以访问特定的IPv6服务（例如，仅针对客户的NNTP服务器）。下文将更详细地描述前者。后者可以通过确保所有特定于服务的IPv4访问列表都有等效的IPv6访问列表来实现。
IPv6-specific user authentication is not always required. An example would be a customer of the IPv4 service automatically having access to the IPv6 service. In this case, the IPv4 access control also provides access to the IPv6 services.
并非总是需要IPv6特定的用户身份验证。例如，IPv4服务的客户可以自动访问IPv6服务。在这种情况下，IPv4访问控制还提供对IPv6服务的访问。
When a provider does not wish to give its IPv4 customers automatic access to IPv6 services, specific IPv6 access control must be performed parallel with the IPv4 access control. This does not imply that different user authentication must be performed for IPv6, but merely that the authentication process may lead to different results for IPv4 and IPv6 access.
当提供商不希望让其IPv4客户自动访问IPv6服务时，特定的IPv6访问控制必须与IPv4访问控制并行执行。这并不意味着必须对IPv6执行不同的用户身份验证，而只是身份验证过程可能会导致IPv4和IPv6访问的不同结果。
Access control traffic may use IPv4 or IPv6 transport. For instance, RADIUS [RFC2865] traffic related to IPv6 service can be transported over IPv4.
访问控制流量可以使用IPv4或IPv6传输。例如，与IPv6服务相关的RADIUS[RFC2865]流量可以通过IPv4进行传输。
The customer connection networks are composed of PE and CPE(s). Usually, each PE connects multiple CPE components to the backbone network infrastructure. This number may reach tens of thousands of customers, or more. The configuration of CPE is difficult for the ISP, and it is even more difficult when it must be done remotely. In this context, the use of auto-configuration mechanisms is beneficial, even if manual configuration is still an option.
客户连接网络由PE和CPE组成。通常，每个PE将多个CPE组件连接到骨干网络基础设施。这一数字可能达到数万或更多的客户。CPE的配置对于ISP来说是困难的，而当必须远程完成时，配置就更加困难了。在这种情况下，使用自动配置机制是有益的，即使手动配置仍然是一种选择。
The parameters that usually need to be provided to customers automatically are as follows:
通常需要自动提供给客户的参数如下：
- The network prefix delegated by the ISP - The address of the Domain Name System server (DNS) - Possibly other parameters (e.g., the address of an NTP server)
- ISP委托的网络前缀-域名系统服务器（DNS）的地址-可能还有其他参数（例如NTP服务器的地址）
When user identification is required on the ISP's network, DHCPv6 may be used to provide configurations; otherwise, either DHCPv6 or a stateless mechanism may be used. This is discussed in more detail in [DUAL-ACCESS].
当ISP网络上需要用户标识时，可使用DHCPv6提供配置；否则，可以使用DHCPv6或无状态机制。这将在[双访问]中进行更详细的讨论。
Note that when the customer connection network is shared between the users or the ISPs and is not just a point-to-point link, authenticating the configuration of the parameters (especially prefix delegation) requires further study.
请注意，当用户或ISP之间共享客户连接网络且不只是点到点链路时，需要进一步研究参数配置（尤其是前缀委派）的身份验证。
As long as IPv4 service is available alongside IPv6, it is not required to auto configure IPv6 parameters in the CPE, except the prefix, because the IPv4 settings may be used.
只要IPv4服务与IPv6同时可用，就不需要在CPE中自动配置IPv6参数（前缀除外），因为可以使用IPv4设置。
Most ISPs have some kind of mechanism to trace the origin of traffic in their networks. This also has to be available for IPv6 traffic, meaning that a specific IPv6 address or prefix has to be tied to a
大多数ISP都有某种机制来追踪其网络中的流量来源。这也必须适用于IPv6流量，这意味着特定的IPv6地址或前缀必须绑定到
certain customer, or that records must be maintained of which customer had which address or prefix. This also applies to the customers with tunneled connectivity.
某些客户，或者必须维护记录，记录哪些客户有哪个地址或前缀。这也适用于具有隧道连接的客户。
This can be done, for example, by mapping a DHCP response to a physical connection and storing the result in a database. It can also be done by assigning a static address or prefix to the customer. A tunnel server could also provide this mapping.
例如，可以通过将DHCP响应映射到物理连接并将结果存储在数据库中来实现。也可以通过为客户分配静态地址或前缀来完成。隧道服务器也可以提供这种映射。
Ingress filtering must be deployed toward the customers, everywhere, to ensure traceability, to prevent DoS attacks using spoofed addresses, to prevent illegitimate access to the management infrastructure, and so on.
必须在任何地方向客户部署入口过滤，以确保可追溯性，防止使用伪造地址的DoS攻击，防止非法访问管理基础设施，等等。
Ingress filtering can be done, for example, by using access lists or Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are described in [RFC3704].
例如，可以通过使用访问列表或单播反向路径转发（uRPF）来完成入口过滤。[RFC3704]中描述了这些机制。
Customers may desire multihoming or multi-connecting for a number of reasons [RFC3582].
客户可能出于多种原因需要多址或多连接[RFC3582]。
Mechanisms for multihoming to more than one ISP are still under discussion. One working model would deploy at least one prefix per ISP and choose the prefix from the ISP to which traffic is sent. In addition, tunnels may be used for robustness [RFC3178]. Currently, there are no provider-independent addresses for end-sites. Such addresses would enable IPv4-style multihoming, with associated disadvantages.
多归属于多个ISP的机制仍在讨论中。一种工作模式是，每个ISP至少部署一个前缀，并从向其发送流量的ISP中选择前缀。此外，隧道可用于坚固性[RFC3178]。目前，终端站点没有独立于提供商的地址。这样的地址将支持IPv4风格的多宿主，但也存在相关的缺点。
Multi-connecting more than once to one ISP is a simple practice, and this can be done, for example, by using BGP with public or private AS numbers and a prefix assigned to the customer.
多次连接到一个ISP是一种简单的做法，这可以通过使用BGP来实现，例如，将公用或专用作为号码，并将前缀分配给客户。
In most networks, quality of service in one form or another is important.
在大多数网络中，某种形式的服务质量很重要。
Naturally, the introduction of IPv6 should not impair existing Service Level Agreements (SLAs) or similar quality assurances.
当然，IPv6的引入不应损害现有的服务级别协议（SLA）或类似的质量保证。
During the deployment of the IPv6 service, the service could be best effort or similar, even if the IPv4 service has an SLA. In the end, both IP versions should be treated equally.
在部署IPv6服务期间，该服务可以是尽力而为或类似的服务，即使IPv4服务具有SLA。最后，两个IP版本应该被平等对待。
IntServ and DiffServ are equally applicable to IPv6 and IPv4 and work similarly regardless of IP version. Of the two, typically only DiffServ has been implemented.
IntServ和DiffServ同样适用于IPv6和IPv4，并且无论IP版本如何，其工作方式都类似。在这两者中，通常只实现了DiffServ。
Many bandwidth provisioning systems operate with IPv4 assumptions, e.g., taking an IPv4 address or (set of) prefixes for which traffic is reserved or preferred. These systems require special attention when introducing IPv6 support in the networks.
许多带宽供应系统使用IPv4假设运行，例如，采用保留或首选流量的IPv4地址或（一组）前缀。在网络中引入IPv6支持时，需要特别注意这些系统。
The network and service operation actions fall into different categories as listed below:
网络和服务运营行动分为以下不同类别：
- Set up IPv6 connectivity to upstream providers and peers - IPv6 network device configuration: for initial configuration and updates - IPv6 network management - IPv6 monitoring - IPv6 customer management - IPv6 network and service operation security
- 设置到上游提供商和对等方的IPv6连接-IPv6网络设备配置：用于初始配置和更新-IPv6网络管理-IPv6监控-IPv6客户管理-IPv6网络和服务操作安全
Some of these items will require an available IPv6 native transport layer and others will not.
其中一些项目将需要可用的IPv6本机传输层，而其他项目则不需要。
As a first step, network device configuration and regular network management operations can be performed over an IPv4 transport, because IPv6 MIBs are also available. Nevertheless, some monitoring functions require the availability of IPv6 transport. This is the case, for instance, when ICMPv6 messages are used by the monitoring applications.
作为第一步，可以通过IPv4传输执行网络设备配置和常规网络管理操作，因为IPv6 MIB也可用。然而，某些监控功能需要IPv6传输的可用性。例如，当监控应用程序使用ICMPv6消息时，就是这种情况。
On many platforms, the current inability to retrieve separate IPv4 and IPv6 traffic statistics from dual-stack interfaces for management purposes by using SNMP is an issue.
在许多平台上，当前无法使用SNMP从双堆栈接口检索单独的IPv4和IPv6流量统计数据以进行管理，这是一个问题。
As a second step, IPv6 transport can be provided for any of these network and service operation facilities.
作为第二步，可以为这些网络和服务运营设施中的任何一个提供IPv6传输。
At some point, an ISP may want to change to a service that is IPv6 only, at least in certain parts of its network. This transition creates many new cases into which continued maintenance of the IPv4 service must be factored. Providing an IPv6-only service is not much different from the dual IPv4/IPv6 service described in stage 3 except for the need to phase out the IPv4 service. The delivery of IPv4 services over an IPv6 network and the phaseout of IPv4 are issues
在某个时刻，ISP可能希望更改为仅限IPv6的服务，至少在其网络的某些部分是这样。这种转变产生了许多新情况，必须考虑IPv4服务的持续维护。提供纯IPv6服务与第3阶段中描述的双IPv4/IPv6服务差别不大，只是需要逐步淘汰IPv4服务。通过IPv6网络提供IPv4服务以及IPv4的逐步淘汰都是问题
left for a subsequent document. Note that there are some services which will need to maintain IPv4 connectivity (e.g., authorative and some recursive DNS servers [DNSGUIDE]).
留作后续文档。请注意，有些服务需要维护IPv4连接（例如，授权和一些递归DNS服务器[DNSGUIDE]）。
This section tries to summarize the potential items requiring specification in the IETF.
本节试图总结IETF中需要规范的潜在项目。
Work items for which an approach was not yet apparent as of this writing are as follows:
截至撰写本文时，尚未明确方法的工作项目如下：
- A tunnel server/broker mechanism, for the cases where the customer connection networks cannot be upgraded, needs to be specified [TUNREQS]. - An IPv6 site multihoming mechanism (or multiple ones) needs to be developed.
- 对于无法升级客户连接网络的情况，需要指定隧道服务器/代理机制[TUNREQS]。-需要开发IPv6站点多主机制（或多个）。
Work items which were already fast in progress, as of this writing, are as follows:
截至撰写本文时，已经快速进行的工作项目如下：
- 6PE for MPLS was identified as a required mechanism, and this is already in progress [BGPTUNNEL]. - IS-IS for Multiple Topologies was noted as a helpful mechanism in certain environments; however, it is possible to use alternative methods to achieve the same end, so specifying this is not strictly required.
- MPLS的6PE被确定为一种必需的机制，并且该机制已经在进行中[BGPTUNNEL]。-IS-IS用于多种拓扑，在某些环境中被认为是一种有用的机制；但是，也可以使用其他方法来达到相同的目的，因此不严格要求指定这一点。
This section presents a number of different example networks. These will not necessarily match any existing networks but are intended to be useful even when they do not correspond to specific target networks. The purpose is to exemplify the applicability of the transition mechanisms described in this document to a number of different situations with different prerequisites.
本节介绍了许多不同的示例网络。这些网络不一定与任何现有网络匹配，但即使它们不对应于特定的目标网络，它们也是有用的。目的是举例说明本文件所述的过渡机制适用于具有不同先决条件的许多不同情况。
The sample network layout will be the same in each network example. This should be viewed as a specific representation of a generic network with a limited number of network devices. A small number of routers have been used in the examples. However, because the network examples follow the implementation strategies recommended for the generic network scenario, it should be possible to scale the examples to fit a network with an arbitrary number, e.g., several hundreds or thousands of routers.
每个网络示例中的示例网络布局都相同。这应被视为具有有限数量网络设备的通用网络的特定表示。示例中使用了少量路由器。然而，由于网络示例遵循针对一般网络场景建议的实施策略，因此应该可以扩展示例以适合具有任意数量（例如数百或数千个路由器）的网络。
The routers in the sample network layout are interconnected with each other and with another ISP. The connection to another ISP can be either direct or through an exchange point. A number of customer connection networks are also connected to the routers. Customer connection networks can be, for example, xDSL or cable network equipment.
示例网络布局中的路由器彼此互连，并与另一个ISP互连。与其他ISP的连接可以是直接连接，也可以是通过交换点连接。许多客户连接网络也连接到路由器。例如，客户连接网络可以是xDSL或有线网络设备。
ISP1 | ISP2
+------+ | +------+
| | | | |
|Router|--|--|Router|
| | | | |
+------+ | +------+
/ \ +-----------------------
/ \
/ \
+------+ +------+
| | | |
|Router|----|Router|
| | | |
+------+ +------+\
| | \ | Exchange point
+------+ +------+ \ +------+ | +------+
| | | | \_| | | | |--
|Router|----|Router|----\|Router|--|--|Switch|--
| | | | | | | | |--
+------+ /+------+ +------+ | +------+
| / | |
+-------+/ +-------+ |
| | | |
|Access1| |Access2|
| | | |
+-------+ +-------+
||||| ||||| ISP Network
----|-----------|----------------------
| | Customer Networks
+--------+ +--------+
| | | |
|Customer| |Customer|
| | | |
+--------+ +--------+
ISP1 | ISP2
+------+ | +------+
| | | | |
|Router|--|--|Router|
| | | | |
+------+ | +------+
/ \ +-----------------------
/ \
/ \
+------+ +------+
| | | |
|Router|----|Router|
| | | |
+------+ +------+\
| | \ | Exchange point
+------+ +------+ \ +------+ | +------+
| | | | \_| | | | |--
|Router|----|Router|----\|Router|--|--|Switch|--
| | | | | | | | |--
+------+ /+------+ +------+ | +------+
| / | |
+-------+/ +-------+ |
| | | |
|Access1| |Access2|
| | | |
+-------+ +-------+
||||| ||||| ISP Network
----|-----------|----------------------
| | Customer Networks
+--------+ +--------+
| | | |
|Customer| |Customer|
| | | |
+--------+ +--------+
Figure 3: ISP Sample Network Layout
图3:ISP示例网络布局
Example 1 presents a network built according to the sample network layout with a native IPv4 backbone. The backbone is running IS-IS and IBGP as routing protocols for internal and external routes, respectively. Multiprotocol BGP is used to exchange routes over the connections to ISP2 and the exchange point. Multicast using PIM-SM routing is present. QoS using DiffServ is deployed.
示例1展示了根据示例网络布局构建的网络，该网络具有本机IPv4主干。主干网分别作为内部和外部路由的路由协议运行is-is和IBGP。多协议BGP用于通过与ISP2和交换点的连接交换路由。存在使用PIM-SM路由的多播。部署了使用DiffServ的QoS。
Access 1 is xDSL connected to the backbone through an access router. The xDSL equipment, except for the access router, is considered to be layer 2 only, e.g., Ethernet or ATM. IPv4 addresses are dynamically assigned to the customer with DHCP. No routing information is exchanged with the customer. Access control and traceability are performed in the access router. Customers are separated into VLANs or separate ATM PVCs up to the access router.
接入1是通过接入路由器连接到主干的xDSL。除接入路由器外，xDSL设备仅被视为第2层，例如以太网或ATM。IPv4地址通过DHCP动态分配给客户。没有与客户交换路由信息。访问控制和可追溯性在访问路由器中执行。客户被分成VLAN或独立的ATM PVC，直至接入路由器。
Access 2 is "fiber to the building or home" (FTTB/H) connected directly to the backbone router. This connection is considered layer-3-aware, because it uses layer 3 switches and performs access control and traceability through its layer 3 awareness by using DHCP snooping. IPv4 addresses are dynamically assigned to the customers with DHCP. No routing information is exchanged with the customer.
接入2是直接连接到主干路由器的“建筑物或家庭光纤”（FTTB/H）。此连接被认为是第3层感知的，因为它使用第3层交换机，并通过使用DHCP窥探通过其第3层感知执行访问控制和跟踪。IPv4地址通过DHCP动态分配给客户。没有与客户交换路由信息。
The actual IPv6 deployment might start by enabling IPv6 on a couple of backbone routers, configuring tunnels between them (if not adjacent) and connecting to a few peers or upstream providers (either through tunnels or at an internet exchange).
实际的IPv6部署可以从在两个主干路由器上启用IPv6开始，在它们之间配置隧道（如果不相邻的话）并连接到几个对等方或上游提供商（通过隧道或在internet交换机）。
After a trial period, the rest of the backbone is upgraded to dual-stack, and IS-IS, without multi-topology extensions (the upgrade order is considered with care), is used as an IPv6 and IPv4 IGP. During an upgrade until IPv6 customers are connected behind a backbone router, the convexity requirement is not critical: The routers will just not be reachable with IPv6. Software supporting IPv6 could be installed even though the routers would not be used for (customer) IPv6 traffic yet. That way, IPv6 could be enabled in the backbone as needed.
经过一段试用期后，主干网的其余部分将升级为双堆栈，并且is-is（不带多拓扑扩展）将用作IPv6和IPv4 IGP（升级顺序需慎重考虑）。在升级过程中，直到IPv6客户连接到主干路由器之后，凸性要求并不重要：IPv6将无法访问路由器。即使路由器尚未用于（客户）IPv6通信，也可以安装支持IPv6的软件。这样，可以根据需要在主干网中启用IPv6。
Separate IPv6 BGP sessions are built similarly to IPv4. Multicast (through SSM and Embedded-RP) and DiffServ are offered at a later phase of the network, e.g., after a year of stable IPv6 unicast operations.
独立的IPv6 BGP会话构建方式与IPv4类似。多播（通过SSM和嵌入式RP）和区分服务在网络的后期阶段提供，例如，在一年稳定的IPv6单播操作之后。
Offering native service as quickly as possible is important. In the meantime, however, a 6to4 relay may be provided in the meantime for optimized 6to4 connectivity and may also be combined with a tunnel broker for extended functionality. Operating as bridges at Layer 2
尽快提供本机服务非常重要。然而，同时可以提供6to4中继以优化6to4连接，并且还可以与隧道代理结合以扩展功能。作为第2层的桥梁运行
only, xDSL equipment does not require changes in CPE: IPv6 connectivity can be offered to the customers by upgrading the PE router to IPv6. In the initial phase, only Router Advertisements are used; DHCPv6 Prefix Delegation can be added as the next step if no other mechanisms are available.
只是，xDSL设备不需要更改CPE：通过将PE路由器升级到IPv6，可以向客户提供IPv6连接。在初始阶段，仅使用路由器广告；如果没有其他机制可用，可以在下一步添加DHCPv6前缀委派。
The FTTB/H access has to be upgraded to support access control and traceability in the switches, probably by using DHCP snooping or a similar IPv6 capability, but it also has to be compatible with prefix delegation, not just address assignment. This could, however, lead to the necessity to use DHCPv6 for address assignment.
FTTB/H访问必须升级，以支持交换机中的访问控制和跟踪，可能是通过使用DHCP侦听或类似的IPv6功能，但它还必须与前缀委派兼容，而不仅仅是地址分配。然而，这可能导致有必要使用DHCPv6进行地址分配。
In example 2, the backbone is running IPv4 with MPLS and is using OSPF and IBGP for internal and external routes, respectively. The connections to ISP2 and the exchange point run BGP to exchange routes. Multicast and QoS are not deployed.
在示例2中，主干网使用MPLS运行IPv4，并将OSPF和IBGP分别用于内部和外部路由。到ISP2和交换点的连接运行BGP到交换路由。未部署多播和QoS。
Access 1 is a fixed line, e.g., fiber, connected directly to the backbone. Routing information is in some cases exchanged with CPE at the customer's site; otherwise static routing is used. Access 1 can also be connected to a BGP/MPLS-VPN running in the backbone.
接入1是一条固定线路，例如光纤，直接连接到主干网。在某些情况下，路由信息在客户现场与CPE交换；否则使用静态路由。接入1还可以连接到主干网中运行的BGP/MPLS-VPN。
Access 2 is xDSL connected directly to the backbone router. The xDSL is layer 2 only, and access control and traceability are achieved through PPPoE/PPPoA. PPP also provides address assignment. No routing information is exchanged with the customer.
接入2是直接连接到主干路由器的xDSL。xDSL仅为第2层，访问控制和可追溯性通过PPPoE/PPPoA实现。PPP还提供地址分配。没有与客户交换路由信息。
IPv6 deployment might start with an upgrade of a couple of PE routers to support [BGPTUNNEL], as this will allow large-scale IPv6 support without hardware or software upgrades in the core. In a later phase, native IPv6 traffic or IPv6 LSPs would be used in the whole network. In this case, IS-IS or OSPF could be used for the internal routing, and a separate IPv6 BGP session would be run.
IPv6部署可能从升级几台PE路由器开始，以支持[BGPTUNNEL]，因为这将允许大规模IPv6支持，而无需核心的硬件或软件升级。在以后的阶段，整个网络将使用本机IPv6流量或IPv6 LSP。在这种情况下，IS-IS或OSPF可用于内部路由，并将运行单独的IPv6 BGP会话。
For the fixed-line customers, the CPE has to be upgraded, and prefix delegation using DHCPv6 or static assignment would be used. An IPv6 MBGP session would be used when routing information has to be exchanged. In the xDSL case, the same conditions for IP-tunneling apply as in Example 1. In addition to IP-tunneling, a PPP session can be used to offer IPv6 access to a limited number of customers. Later, when clients and servers have been updated, the IPv6 PPP session can be replaced with a combined PPP session for both IPv4 and IPv6. PPP has to be used for address and prefix assignment.
对于固定线路客户，必须升级CPE，并使用使用DHCPv6或静态分配的前缀委派。当必须交换路由信息时，将使用IPv6 MBGP会话。在xDSL的情况下，IP隧道的条件与示例1中相同。除了IP隧道外，PPP会话还可用于向有限数量的客户提供IPv6访问。稍后，在更新客户端和服务器后，可以将IPv6 PPP会话替换为IPv4和IPv6的组合PPP会话。地址和前缀分配必须使用PPP。
A transit provider offers IP connectivity to other providers, but not to end users or enterprises. IS-IS and IBGP are used internally, and BGP is used externally. Its accesses connect Tier-2 provider cores. No multicast or QoS is used.
运输提供商向其他提供商提供IP连接，但不向最终用户或企业提供。IS-IS和IBGP在内部使用，BGP在外部使用。其访问连接第2层提供程序核心。没有使用多播或QoS。
As this type of transit provider has a number of customers, who have a large number of customers in turn, it obtains an address allocation from an RIR. The whole backbone can be upgraded to dual-stack in a reasonably short time after a trial with a couple of routers. IPv6 routing is performed by using the same IS-IS process and separate IPv6 BGP sessions.
由于这种类型的公交服务提供商拥有大量的客户，而这些客户又拥有大量的客户，因此它从RIR获得地址分配。经过几台路由器的试用，整个主干网可以在相当短的时间内升级到双栈。IPv6路由通过使用相同的is-is进程和单独的IPv6 BGP会话来执行。
The ISP provides IPv6 transit to its customers for free, as a competitive advantage. It also provides, at the first phase only, a configured tunnel service with BGP peering to the significant sites and customers (those with an AS number) who are the customers of its customers whenever its own customer networks are not offering IPv6. This is done both to introduce them to IPv6 and to create a beneficial side effect: A bit of extra revenue is generated from its direct customers as the total amount of transited traffic grows.
作为竞争优势，ISP向其客户免费提供IPv6传输。它还仅在第一阶段提供配置的隧道服务，当其客户网络不提供IPv6时，BGP将对等到重要站点和客户（具有AS编号的客户）。这样做既是为了将它们引入IPv6，也是为了产生一个有益的副作用：随着传输流量总量的增长，直接客户会产生一点额外的收入。
This document analyzes scenarios and identifies transition mechanisms that could be used for the scenarios. It does not introduce any new security issues. Security considerations of each mechanism are described in the respective documents.
本文档分析场景并确定可用于场景的转换机制。它不会带来任何新的安全问题。每个机制的安全注意事项在各自的文档中进行了描述。
However, a few generic observations are in order.
然而，一些一般性的观察结果是正确的。
o Introducing IPv6 adds new classes of security threats or requires adopting new protocols or operational models than those for IPv4; typically these are generic issues, to be discussed further in other documents, for example, [V6SEC].
o 引入IPv6增加了新的安全威胁类别，或者需要采用比IPv4更新的协议或操作模型；通常，这些是一般性问题，将在其他文档中进一步讨论，例如，[V6SEC]。
o The more complex the transition mechanisms employed become, the more difficult it will be to manage or analyze their impact on security. Consequently, simple mechanisms are preferable.
o 所采用的过渡机制越复杂，管理或分析其对安全性的影响就越困难。因此，简单的机制更可取。
o This document has identified a number of requirements for analysis or further work that should be explicitly considered when adopting IPv6: how to perform access control over shared media or shared ISP customer connection media, how to manage the configuration management security on such environments
o 本文档确定了在采用IPv6时应明确考虑的一些分析或进一步工作要求：如何对共享介质或共享ISP客户连接介质执行访问控制，如何管理此类环境中的配置管理安全
(e.g., DHCPv6 authentication keying), and how to manage customer traceability if stateless address autoconfiguration is used.
（例如，DHCPv6身份验证键控），以及在使用无状态地址自动配置时如何管理客户可跟踪性。
This document has greatly benefited from input by Marc Blanchet, Jordi Palet, Francois Le Faucheur, Ronald van der Pol, and Cleve Mickles.
本文件从Marc Blanchet、Jordi Palet、Francois Le Faucheur、Ronald van der Pol和Cleve Mickles的输入中获益匪浅。
Special thanks to Richard Graveman and Michael Lambert for proofreading the document.
特别感谢Richard Graveman和Michael Lambert校对该文件。
[EMBEDRP] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[EMBEDRP]Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，RFC 3956，2004年11月。
[MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M-ISIS: Multi Topology (MT) Routing in IS-IS", Work in Progress.
[MTISIS]Przygienda，T.，沈乃明，Nischal Sheth，“M-ISIS:IS-IS中的多拓扑（MT）路由”，正在进行中。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC2858]Bates，T.，Rekhter，Y.，Chandra，R.，和D.Katz，“BGP-4的多协议扩展”，RFC 2858，2000年6月。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC2545]Marques，P.和F.Dupont，“将BGP-4多协议扩展用于IPv6域间路由”，RFC 25451999年3月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582]Abley，J.，Black，B.和V.Gill，“IPv6站点多主架构的目标”，RFC 3582，2003年8月。
[RFC3178] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at Site Exit Routers", RFC 3178, October 2001.
[RFC3178]Hagino，J.和H.Snyder，“站点出口路由器的IPv6多主支持”，RFC 3178，2001年10月。
[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月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[BGPTUNNEL] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le Faucheur, F., "Connecting IPv6 Islands across IPv4 Clouds with BGP", Work in Progress.
[BGPTUNNEL]De Clercq，J.，Gastaud，G.，Ooms，D.，Prevost，S.，Le Faucheur，F.，“使用BGP跨IPv4云连接IPv6孤岛”，工作正在进行中。
[DUAL-ACCESS] Shirasaki, Y., Miyakawa, S., Yamasaki, T., Takenouchi, A., "A Model of IPv6/IPv4 Dual Stack Internet Access Service", Work in Progress.
[双访问]Shirasaki，Y.，Miyakawa，S.，Yamasaki，T.，Takenouchi，A.，“IPv6/IPv4双栈互联网访问服务的模型”，正在进行中。
[STEP] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", Work in Progress.
[步骤]Savola，P.，“简单IPv6-in-IPv4隧道建立过程（步骤）”，正在进行中。
[TSP] Blanchet, M., "IPv6 Tunnel Broker with Tunnel Setup Protocol (TSP)", Work in Progress.
[TSP]Blanchet，M.，“具有隧道设置协议（TSP）的IPv6隧道代理”，工作正在进行中。
[TUNREQS] Palet, J., Nielsen, K., Parent, F., Durand, A., Suryanarayanan, R., and P. Savola, "Goals for Tunneling Configuration", Work in Progress, February 2005.
[TUNREQS]Palet，J.，Nielsen，K.，Parent，F.，Durand，A.，Suryanarayanan，R.，和P.Savola，“隧道结构的目标”，正在进行的工作，2005年2月。
[UNMANEVA] Huitema, C., Austein, R., Satapati, S., van der Pol, R., "Evaluation of Transition Mechanisms for Unmanaged Networks", Work in Progress.
[UNMANEVA]Huitema，C.，Austein，R.，Satapati，S.，van der Pol，R.，“非托管网络过渡机制的评估”，正在进行的工作。
[PROTO41] Palet, J., Olvera, C., Fernandez, D., "Forwarding Protocol 41 in NAT Boxes", Work in Progress.
[PROTO41]Palet，J.，Olvera，C.，Fernandez，D.，“NAT盒中的转发协议41”，正在进行中。
[V6SEC] Savola, P., "IPv6 Transition/Co-existence Security Considerations", Work in Progress.
[V6SEC]Savola，P.，“IPv6过渡/共存安全考虑”，正在进行中。
[DNSGUIDE] Durand, A., Ihren, J., "DNS IPv6 transport operational guidelines", Work in Progress.
[DNSGUIDE]Durand，A.，Ihren，J.，“DNS IPv6传输操作指南”，正在进行的工作。
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", Work in Progress.
[TEREDO]Huitema，C.，“TEREDO：通过NAT通过UDP传输IPv6”，工作正在进行中。
Appendix A: Convexity Requirements in Single Topology IS-IS
附录A：单一拓扑IS-IS中的凸性要求
The single-topology IS-IS convexity requirements could be summarized, from IPv4/6 perspective, as follows:
从IPv4/6的角度来看，单拓扑IS-IS凸性要求可以总结如下：
1) "any IP-independent path from an IPv4 router to any other IPv4 router must only go through routers which are IPv4-capable", and
1) “从IPv4路由器到任何其他IPv4路由器的任何IP独立路径必须仅通过支持IPv4的路由器”，以及
2) "any IP-independent path from an IPv6 router to any other IPv6 router must only go through routers which are IPv6-capable".
2) “从IPv6路由器到任何其他IPv6路由器的任何IP独立路径必须仅通过支持IPv6的路由器”。
As IS-IS is based upon CLNS, these are not trivially accomplished. The single-topology IS-IS builds paths which are agnostic of IP versions.
由于IS-IS是基于CLN的，这些并不是很容易实现的。单一拓扑IS-IS构建的路径与IP版本无关。
Consider an example scenario of three IPv4/IPv6-capable routers and an IPv4-only router:
考虑三个IPv4/IPv6路由器和IPv4路由器的示例场景：
cost 5 R4 cost 5
,------- [v4/v6] -----.
/ \
[v4/v6] ------ [ v4 ] -----[v4/v6]
R1 cost 3 R3 cost 3 R2
cost 5 R4 cost 5
,------- [v4/v6] -----.
/ \
[v4/v6] ------ [ v4 ] -----[v4/v6]
R1 cost 3 R3 cost 3 R2
Here the second requirement would not hold. IPv6 packets from R1 to R2 (or vice versa) would go through R3, which does not support IPv6, and the packets would get discarded. By reversing the costs between R1-R3, R3-R2 and R1-R4,R4-R2 the traffic would work in the normal case, but if a link fails and the routing changes to go through R3, the packets would start being discarded again.
在这里，第二个要求不成立。从R1到R2（反之亦然）的IPv6数据包将经过不支持IPv6的R3，这些数据包将被丢弃。通过逆转R1-R3、R3-R2和R1-R4、R4-R2之间的成本，流量将在正常情况下正常工作，但如果链路失败，路由更改为通过R3，数据包将再次开始被丢弃。
Authors' Addresses
作者地址
Mikael Lind TeliaSonera Vitsandsgatan 9B SE-12386 Farsta, Sweden
Mikael Lind TeliaSonera Vitsandsgatan 9B SE-12386瑞典法尔斯塔
EMail: mikael.lind@teliasonera.com
EMail: mikael.lind@teliasonera.com
Vladimir Ksinant Thales Communications 160, boulevard de Valmy 92704 Colombes, France
弗拉基米尔·克西南特·泰利斯通讯160号，法兰西科伦坡瓦尔米大道92704号
EMail: vladimir.ksinant@fr.thalesgroup.com
EMail: vladimir.ksinant@fr.thalesgroup.com
Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics. 416, Maetan-3dong, Paldal-Gu, Suwon, Gyeonggi-do, Korea
Soohong Daniel Park移动平台实验室，三星电子。韩国京畿道水原Paldal Gu Maetan-3栋416号
EMail: soohong.park@samsung.com
EMail: soohong.park@samsung.com
Alain Baudot France Telecom R&D Division 42, rue des coutures 14066 Caen - FRANCE
阿兰·博多特法国电信研发部42号，法国卡昂大道14066号
EMail: alain.baudot@francetelecom.com
EMail: alain.baudot@francetelecom.com
Pekka Savola CSC/FUNET Espoo, Finland
佩卡·萨沃拉CSC/FUNET Espoo，芬兰
EMail: psavola@funet.fi
EMail: psavola@funet.fi
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。