Network Working Group J. Bound
Request for Comments: 4852 Y. Pouffary
Category: Informational Hewlett-Packard
S. Klynsma
MITRE
T. Chown
University of Southampton
D. Green
Command Information
April 2007
Network Working Group J. Bound
Request for Comments: 4852 Y. Pouffary
Category: Informational Hewlett-Packard
S. Klynsma
MITRE
T. Chown
University of Southampton
D. Green
Command Information
April 2007
IPv6 Enterprise Network Analysis - IP Layer 3 Focus
IPv6企业网络分析-IP第3层重点
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network.
本文档分析了企业网络向IPv6的过渡，重点是IP第3层。这些网络的特征是具有多个内部链路和到一个或多个提供商的一个或多个路由器连接，并且由网络操作实体管理。该分析侧重于一组基本的过渡符号网络和需求，这些网络和需求是从以前的企业场景文档扩展而来的。假设企业内有一个双IP层（IPv4和IPv6）网络和节点环境，本文将重点讨论企业向IPv6过渡所需的一组过渡分析。然后，为每个符号网络推荐一组转换机制。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Enterprise Matrix Analysis for Transition .......................5
4. Wide-Scale Dual-Stack Deployment Analysis ......................10
4.1. Staged Dual-Stack Deployment ..............................10
4.2. Routing Capability Analysis for Dual-IP Deployment ........11
4.2.1. IPv6 Routing Capability ............................11
4.2.2. IPv6 Routing Non-Capability ........................11
4.2.2.1. Tunnel IPv6 over the IPv4 infrastructure ..12
4.2.2.2. Deploy a Parallel IPv6 Infrastructure .....12
4.3. Remote IPv6 Access to the Enterprise ......................12
4.4. Other Considerations ......................................13
5. Sparse Dual-Stack Deployment Analysis ..........................13
5.1. Internal versus External Tunnel Endpoint ..................13
5.2. Manual versus Autoconfigured ..............................14
6. IPv6-Dominant Network Deployment Analysis ......................14
7. General Issues from Analysis ...................................15
7.1. Staged Plan for IPv6 Deployment ...........................15
7.2. Network Infrastructure Requirements .......................15
7.3. Stage 1: Initial Connectivity Steps .......................15
7.3.1. Obtaining External Connectivity ....................16
7.3.2. Obtaining Global IPv6 Address Space ................16
7.4. Stage 2: Deploying Generic Basic Service Components .......16
7.4.1. Developing an IPv6 Addressing Plan .................16
7.4.2. IPv6 DNS ...........................................17
7.4.3. IPv6 Routing .......................................17
7.4.4. Configuration of Hosts .............................18
7.4.5. Security ...........................................18
7.5. Stage 3: Widespread Dual-Stack Deployment On-Site .........19
8. Applicable Transition Mechanisms ...............................20
8.1. Recognizing Incompatible Network Touchpoints ..............20
8.2. Recognizing Application Incompatibilities .................21
8.3. Using Multiple Mechanisms to Support IPv6 Transition ......22
9. Security Considerations ........................................22
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................24
11. Acknowledgments ...............................................25
Appendix A. Crisis Management Network Scenarios ...................26
A.1. Introduction ..............................................26
A.2. Scenarios for IPv6 Deployment in Crisis Management
Networks ..................................................26
A.3. Description of a Generic Crisis Management Network ........28
A.4. Stages of IPv6 Deployment .................................29
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Enterprise Matrix Analysis for Transition .......................5
4. Wide-Scale Dual-Stack Deployment Analysis ......................10
4.1. Staged Dual-Stack Deployment ..............................10
4.2. Routing Capability Analysis for Dual-IP Deployment ........11
4.2.1. IPv6 Routing Capability ............................11
4.2.2. IPv6 Routing Non-Capability ........................11
4.2.2.1. Tunnel IPv6 over the IPv4 infrastructure ..12
4.2.2.2. Deploy a Parallel IPv6 Infrastructure .....12
4.3. Remote IPv6 Access to the Enterprise ......................12
4.4. Other Considerations ......................................13
5. Sparse Dual-Stack Deployment Analysis ..........................13
5.1. Internal versus External Tunnel Endpoint ..................13
5.2. Manual versus Autoconfigured ..............................14
6. IPv6-Dominant Network Deployment Analysis ......................14
7. General Issues from Analysis ...................................15
7.1. Staged Plan for IPv6 Deployment ...........................15
7.2. Network Infrastructure Requirements .......................15
7.3. Stage 1: Initial Connectivity Steps .......................15
7.3.1. Obtaining External Connectivity ....................16
7.3.2. Obtaining Global IPv6 Address Space ................16
7.4. Stage 2: Deploying Generic Basic Service Components .......16
7.4.1. Developing an IPv6 Addressing Plan .................16
7.4.2. IPv6 DNS ...........................................17
7.4.3. IPv6 Routing .......................................17
7.4.4. Configuration of Hosts .............................18
7.4.5. Security ...........................................18
7.5. Stage 3: Widespread Dual-Stack Deployment On-Site .........19
8. Applicable Transition Mechanisms ...............................20
8.1. Recognizing Incompatible Network Touchpoints ..............20
8.2. Recognizing Application Incompatibilities .................21
8.3. Using Multiple Mechanisms to Support IPv6 Transition ......22
9. Security Considerations ........................................22
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................24
11. Acknowledgments ...............................................25
Appendix A. Crisis Management Network Scenarios ...................26
A.1. Introduction ..............................................26
A.2. Scenarios for IPv6 Deployment in Crisis Management
Networks ..................................................26
A.3. Description of a Generic Crisis Management Network ........28
A.4. Stages of IPv6 Deployment .................................29
This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links, and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network.
本文档分析了企业网络向IPv6的过渡，重点是IP第3层。这些网络的特征是具有多个内部链路和一个或多个到一个或多个提供商的一个或多个路由器连接，并且由网络操作实体管理。该分析侧重于一组基本的过渡符号网络和需求，这些网络和需求是从以前的企业场景文档扩展而来的。假设企业内有一个双IP层（IPv4和IPv6）网络和节点环境，本文将重点讨论企业向IPv6过渡所需的一组过渡分析。然后，为每个符号网络推荐一组转换机制。
The audience for this document is the enterprise network team considering deployment of IPv6. The document will be useful for enterprise teams that have to determine the IPv6 transition strategy for their enterprise. It is expected that those teams include members from management, network operations, and engineering. The analysis and notational networks presented provide an example set of cases the enterprise can use to build an IPv6 transition strategy.
本文档的读者是考虑部署IPv6的企业网络团队。该文档对于必须为其企业确定IPv6过渡策略的企业团队非常有用。预计这些团队包括来自管理层、网络运营部和工程部的成员。本文提供的分析和符号网络为企业构建IPv6过渡策略提供了一组示例案例。
The enterprise analysis begins by describing a matrix as a tool to be used to portray the different IPv4 and IPv6 possibilities for deployment. The document will then provide analysis to support enterprise-wide Dual-IP layer deployment strategy, to provide the reader with a view of how that can be planned and what options are available. The document then discusses the deployment of sparse IPv6 nodes within the enterprise and the requirements that need to be considered and implemented when the enterprise remains with an IPv4- only routing infrastructure for some time. The next discussion focuses on the use of IPv6 when it is determined to be dominant across or within parts of the enterprise network.
企业分析首先将矩阵描述为用于描述不同IPv4和IPv6部署可能性的工具。然后，本文档将提供分析，以支持企业范围的双IP层部署策略，为读者提供如何规划该策略以及哪些选项可用的视图。然后，本文档讨论了稀疏IPv6节点在企业中的部署，以及企业在一段时间内仍然使用仅IPv4路由基础架构时需要考虑和实现的需求。下一个讨论的重点是在确定IPv6在整个企业网络或部分企业网络中占主导地位时使用IPv6。
The document then discusses the general issues and applicability from the previous analysis. The document concludes by providing a set of current transition mechanism recommendations for the notational network scenarios to support an enterprise that is planning to deploy IPv6.
然后，本文件讨论了先前分析中的一般问题和适用性。本文档最后提供了一组当前过渡机制建议，用于支持计划部署IPv6的企业的符号化网络场景。
As stated, this document focuses only on the deployment cases where a Dual-IP Layer 3 is supported across the network and on the nodes in the enterprise. Additional deployment transition analysis will be required from the effects of an IPv6-only node or Provider deployments, and is beyond the scope of this document. In addition, this document does not attempt to define or discuss any use with network address translation [NATPT] or Provider Independent address space.
如上所述，本文档仅关注在网络和企业中的节点上支持双IP层3的部署情况。由于仅IPv6节点或提供商部署的影响，需要进行额外的部署转换分析，这超出了本文档的范围。此外，本文档不试图定义或讨论网络地址转换[NATPT]或独立于提供商的地址空间的任何用途。
The following specific topics are currently out of scope for this document:
以下特定主题目前不在本文档的范围内：
- Multihoming - Application transition/porting (see [APPS]). - IPv6 VPN, firewall, or intrusion detection deployment. - IPv6 network management and QoS deployment. - Detailed IT Department requirements. - Deployment of novel IPv6 services, e.g., Mobile IPv6. - Requirements or Transition at the Providers' network. - Transport protocol selection for applications with IPv6. - Application layer and configuration issues. - IPv6 only future deployment scenarios.
- 多宿主-应用程序转换/移植（请参见[APPS]）-IPv6 VPN、防火墙或入侵检测部署。-IPv6网络管理和QoS部署。-详细的IT部门要求。-部署新型IPv6服务，例如移动IPv6。-供应商网络的要求或转换。-使用IPv6的应用程序的传输协议选择。-应用层和配置问题IPv6仅适用于未来部署场景。
This document focuses on IP Layer 3 deployment in the same way as the other IPv6 deployment analysis works have done [UMAN] [ISPA] [3GPA]. This document covers deployment of IPv6 "on the wire", including address management and DNS services.
本文档以与[UMAN][ISPA][3GPA]中其他IPv6部署分析工作相同的方式关注IP第3层部署。本文档介绍了IPv6“在线”的部署，包括地址管理和DNS服务。
We are also assuming that the enterprise deployment is being undertaken by the network administration team, i.e., this document does not discuss the case of an individual user gaining IPv6 connectivity (to some external IPv6 provider) from within an enterprise network. Much of the analysis is applicable to wireless networks, but there are additional considerations for wireless networks not contained within this document.
我们还假设企业部署由网络管理团队进行，即，本文档不讨论单个用户从企业网络内获得IPv6连接（到某个外部IPv6提供商）的情况。大部分分析适用于无线网络，但本文档中未包含无线网络的其他注意事项。
In Section 2, we introduce the terminology used in this document. In Section 3, we introduce and define a tools matrix and define the IP Layer 3 connectivity requirements. In Section 4, we discuss wide scale Dual-IP layer use within an enterprise. In Section 5, we discuss sparse Dual-IP layer deployment within an enterprise. In Section 6, we discuss IPv6-dominant network deployment within the enterprise. In Section 7, we discuss general issues and applicability. In Section 8, a set of transition mechanisms that can support the deployment of IPv6 with an enterprise are recommended.
在第2节中，我们将介绍本文档中使用的术语。在第3节中，我们将介绍并定义一个工具矩阵，并定义IP第3层连接要求。在第4节中，我们将讨论企业内的大规模双IP层使用。在第5节中，我们将讨论企业内的稀疏双IP层部署。在第6节中，我们将讨论企业内IPv6主导的网络部署。在第7节中，我们将讨论一般性问题和适用性。在第8节中，建议使用一组过渡机制来支持企业部署IPv6。
This document then provides Appendix A for readers depicting a Crisis Management enterprise network to demonstrate an enterprise network example that requires all the properties as analyzed in Sections 3, 4, 5, 6, and 7. In addition, we recommend that readers of this document also read another use-case document to support an IPv6 Transition for a Campus Network [CAMP].
然后，本文档为描述危机管理企业网络的读者提供附录A，以演示企业网络示例，该示例需要第3、4、5、6和7节中分析的所有属性。此外，我们建议本文档的读者也阅读另一个用例文档，以支持校园网[CAMP]的IPv6转换。
Readers should also be aware that a parallel effort for an enterprise to transition to IPv6 is training, but out of scope for this document.
读者还应注意，企业向IPv6过渡的并行工作是培训，但超出了本文档的范围。
Enterprise Network - A network that has multiple internal links, and one or more router connections to one or more Providers, and is actively managed by a network operations entity.
企业网络-具有多个内部链路和一个或多个路由器连接到一个或多个提供商的网络，由网络运营实体主动管理。
Provider - An entity that provides services and connectivity to the Internet or other private external networks for the enterprise network.
提供商-为企业网络提供Internet或其他专用外部网络服务和连接的实体。
IPv6-capable - A node or network capable of supporting both IPv6 and IPv4.
支持IPv6—能够同时支持IPv6和IPv4的节点或网络。
IPv4-only - A node or network capable of supporting only IPv4.
仅IPv4-仅支持IPv4的节点或网络。
IPv6-only - A node or network capable of supporting only IPv6. This does not imply an IPv6 only stack in this document.
仅限IPv6—仅支持IPv6的节点或网络。这并不意味着本文档中只包含IPv6堆栈。
Dual-IP - A network or node that supports both IPv4 and IPv6.
双IP—同时支持IPv4和IPv6的网络或节点。
IP-capability - The ability to support IPv6 only, IPv4 only, or Dual-IP Layer
IP能力—支持仅IPv6、仅IPv4或双IP层的能力
IPv6-dominant - A network running IPv6 routing and control plane services that provides transport for both IPv4 and IPv6 protocol services
IPv6主导-运行IPv6路由和控制平面服务的网络，为IPv4和IPv6协议服务提供传输
Transition - The network strategy the enterprise uses to Implementation transition to IPv6.
过渡-企业用于实现向IPv6过渡的网络战略。
In order to identify the best-suited transition mechanisms for an enterprise, it is recommended that the enterprise have an in-depth up-to-date understanding of its current IT environment. This understanding will help choose the best-suited transition mechanisms. It is important to note that one size does not fit all. Selection of mechanisms that reduce the impact on the existing environment is suggested. When selecting a transition mechanism, one must consider the functionality required, its scalability characteristic, and the security implications of each mechanism.
为了确定最适合企业的过渡机制，建议企业深入了解其当前it环境的最新情况。这种理解将有助于选择最适合的过渡机制。需要注意的是，一种尺寸并不适合所有尺寸。建议选择减少对现有环境影响的机制。在选择过渡机制时，必须考虑所需的功能、可伸缩性以及每个机制的安全含义。
To provide context for an analysis of the transitioning enterprise at Layer 3, we have provided a matrix that describes various scenarios
为了为第3层的过渡企业分析提供上下文，我们提供了一个描述各种场景的矩阵
which might be encountered during an IPv6 transition. The notional enterprise network is comprised of hosts attached to an enterprise-owned intranet(s) at two different global locations separated by the Internet. The enterprise owns, operates, and maintains its own intranetworks, but relies on an external provider organization that offers Internet Service. Both local and destination intranetworks are operated by different organizations within the same enterprise and consequently could have different IP-capability than other intranetworks at certain times in the transition period.
在IPv6转换期间可能会遇到的。概念上的企业网络由连接到企业内部网的主机组成，该企业内部网位于两个不同的全球位置，由Internet隔开。企业拥有、运营和维护自己的内部网络，但依赖于提供互联网服务的外部提供商组织。本地和目的地内部网络都由同一企业内的不同组织运营，因此在过渡期的特定时间，它们的IP能力可能与其他内部网络不同。
Addressing every possible combination of network IP-capability in this notional enterprise network is impractical; therefore, trivial notional networks (i.e., pure IPv4, pure IPv6, and ubiquitous Dual-IP) are not considered. In addition, the authors could not conceive of any scenarios involving IPv6-only ISPs or IPv6-only nodes in the near term and consequently have not addressed scenarios with IPv6- only ISPs or IPv6-only nodes. We assume all nodes that host IPv6 applications are Dual-IP. The matrix does not assume or suggest that network address translation is used. The authors recommend that network address translation not be used in these notional cases.
在这个概念上的企业网络中解决网络IP能力的每一种可能组合都是不切实际的；因此，不考虑简单的概念网络（即纯IPv4、纯IPv6和无处不在的双IP）。此外，作者在近期内无法设想任何涉及仅IPv6 ISP或仅IPv6节点的场景，因此没有涉及仅IPv6 ISP或仅IPv6节点的场景。我们假设承载IPv6应用程序的所有节点都是双IP。该矩阵不假设或建议使用网络地址转换。作者建议在这些概念性的情况下不要使用网络地址转换。
Future enterprise transitions that support IPv6-only nodes and IPv6- only ISPs will require separate analysis, which is beyond the scope of this document.
支持仅IPv6节点和仅IPv6 ISP的未来企业转换将需要单独分析，这超出了本文档的范围。
Table 1 below is a matrix of ten possible Transition Implementations that, being encountered in an enterprise, may require analysis and the selection of an IPv6 transition mechanism for that notional network. Each possible implementation is represented by the rows of the matrix. The matrix describes a set of notional networks as follows:
下面的表1是十种可能的转换实现的矩阵，在企业中遇到这种情况时，可能需要分析和选择该概念网络的IPv6转换机制。每个可能的实现都由矩阵的行表示。矩阵描述了一组概念网络，如下所示：
- The first column represents the protocol used by the application and, below, the IP-capability of the node originating the IP packets. (Application/Host 1 OS)
- 第一列表示应用程序使用的协议，下面是发起IP数据包的节点的IP能力。（应用程序/主机1操作系统）
- The second column represents the IP-capability of the host network wherein the node originated the packet. (Host 1 Network)
- 第二列表示节点发起数据包的主机网络的IP能力。（主机1网络）
- The third column represents the IP-capability of the service provider network. (Service Provider)
- 第三列表示服务提供商网络的IP能力。（服务提供商）
- The fourth column represents the IP-capability of the destination network wherein the originating IP packets are received. (Host 2 Network)
- 第四列表示接收发起IP分组的目的地网络的IP能力。（主机2网络）
- The fifth column represents the protocol used by the application and, below, the IP-capability of the destination node receiving the originating IP packets. (Application/Host 2 OS)
- 第五列表示应用程序使用的协议，下面是接收原始IP数据包的目标节点的IP能力。（应用程序/主机2操作系统）
As an example, notional network 1 is an IPv6 application residing on a Dual-IP layer host trying to establish a communications exchange with a destination IPv6 application. To complete the information exchange, the packets must first traverse the host's originating IPv4 network (intranet), then the service provider's and destination host's Dual-IP network.
例如，概念上的网络1是驻留在双IP层主机上的IPv6应用程序，试图与目标IPv6应用程序建立通信交换。要完成信息交换，数据包必须首先通过主机的原始IPv4网络（intranet），然后是服务提供商和目标主机的双IP网络。
Obviously, Table 1 does not describe every possible scenario. Trivial notional networks (such as pure IPv4, pure IPv6, and ubiquitous Dual-IP) are not addressed. However, the authors feel these ten scenarios represent the vast majority of transitional situations likely to be encountered in today's enterprise. Therefore, we will use these ten to address the analysis for enterprise deployment.
显然，表1并没有描述所有可能的情况。不涉及普通的概念网络（如纯IPv4、纯IPv6和无处不在的双IP）。然而，作者认为这十个场景代表了当今企业可能遇到的绝大多数过渡情况。因此，我们将使用这十种方法来分析企业部署。
Table 1 - Enterprise Scenario Deployment Matrix
表1-企业场景部署矩阵
======================================================
|Application |Host 1 |Service |Host 2 |Application |
|----------- |Network|Provider|Network|---------- |
| Host 1 OS | | | | Host 2 OS |
=====================================+================
| IPv6 | |Dual IP | | IPv6 |
A | ---- | IPv4 | or |Dual IP| ---- |
| Dual IP | | IPv4 | | Dual IP |
======================================================
| IPv6 | | | | IPv6 |
B | ---- | IPv6 | IPv4 | IPv4 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 | | | | IPv4 |
C | ---- | IPv4 |Dual IP | IPv6 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 |Dual IP| | | IPv4 |
D | ---- | or | IPv4 | IPv6 | ---- |
| Dual IP | IPv6 | | | Dual IP |
======================================================
| IPv6 |Dual IP| |Dual IP| IPv4 |
E | ---- | or |Dual IP | or | ---- |
| Dual IP | IPv6 | | IPv6 | Dual IP |
======================================================
| IPv6 | | | | IPv4 |
F | ---- | IPv6 | IPv4 | IPv4 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 | | | | IPv6 |
G | ---- | IPv6 | Dual IP| IPv6 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 | | | | IPv6 |
H | ---- | IPv6 |Dual IP | IPv4 | ---- |
| IPv4 | | | | Dual IP |
======================================================
| IPv4 | | | | IPv6 |
I | ---- | IPv6 | IPv4 | IPv6 | ---- |
| IPv4 | | | | Dual IP |
======================================================
| IPv6 | | | | IPv4 |
J | ---- | IPv4 | IPv4 | IPv6 | ---- |
| Dual IP | | | | Dual IP |
======================================================
======================================================
|Application |Host 1 |Service |Host 2 |Application |
|----------- |Network|Provider|Network|---------- |
| Host 1 OS | | | | Host 2 OS |
=====================================+================
| IPv6 | |Dual IP | | IPv6 |
A | ---- | IPv4 | or |Dual IP| ---- |
| Dual IP | | IPv4 | | Dual IP |
======================================================
| IPv6 | | | | IPv6 |
B | ---- | IPv6 | IPv4 | IPv4 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 | | | | IPv4 |
C | ---- | IPv4 |Dual IP | IPv6 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 |Dual IP| | | IPv4 |
D | ---- | or | IPv4 | IPv6 | ---- |
| Dual IP | IPv6 | | | Dual IP |
======================================================
| IPv6 |Dual IP| |Dual IP| IPv4 |
E | ---- | or |Dual IP | or | ---- |
| Dual IP | IPv6 | | IPv6 | Dual IP |
======================================================
| IPv6 | | | | IPv4 |
F | ---- | IPv6 | IPv4 | IPv4 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 | | | | IPv6 |
G | ---- | IPv6 | Dual IP| IPv6 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 | | | | IPv6 |
H | ---- | IPv6 |Dual IP | IPv4 | ---- |
| IPv4 | | | | Dual IP |
======================================================
| IPv4 | | | | IPv6 |
I | ---- | IPv6 | IPv4 | IPv6 | ---- |
| IPv4 | | | | Dual IP |
======================================================
| IPv6 | | | | IPv4 |
J | ---- | IPv4 | IPv4 | IPv6 | ---- |
| Dual IP | | | | Dual IP |
======================================================
The reader should note that Scenarios A-C in Table 1 are variations of compatible hosts communicating across largely (but not entirely) homogenous networks. In each of the first three scenarios, the packet must traverse at least one incompatible network component. For example, Scenario B represents an enterprise that wishes to use IPv6 applications, but has yet to transition its internal networks; its Service Provider also lags, offering only a v4 IP-service. Conversely, Scenario C represents an enterprise that has completed transition to IPv6 in its core networks (as has its Service Provider), but continues to require a legacy IPv4-based application.
读者应注意，表1中的场景A-C是兼容主机的变体，这些主机在大部分（但不完全）同质网络上进行通信。在前三种情况中，数据包必须至少穿过一个不兼容的网络组件。例如，场景B表示希望使用IPv6应用程序但尚未转换其内部网络的企业；其服务提供商也落后，只提供V4IP服务。相反，场景C代表的是一家企业，该企业已在其核心网络中完成了向IPv6的过渡（与服务提供商一样），但仍需要基于IPv4的遗留应用程序。
Scenario D represents the unusual situation where the enterprise has transitioned its core intranetworks to IPv6, but (like Scenario B) it's ISP provider has yet to transition. In addition, this enterprise continues to retain critical legacy IPv4-based applications that must communicate over this heterogeneous network environment.
场景D代表了一种不寻常的情况，即企业已将其核心内部网络过渡到IPv6，但（与场景B一样）其ISP提供商尚未过渡。此外，该企业继续保留必须在此异构网络环境中通信的基于IPv4的关键遗留应用程序。
Scenarios E-J represent transitional situations wherein the enterprise has both IPv4 and IPv6 based instantiations of the same application that must continue to interoperate. In addition, these scenarios show that the enterprise has not completed transition to IPv6 in all its organic and/or Service Provider networks. Instead, it maintains a variety of heterogeneous network segments between the communicating applications. Scenarios E and J represent distinctly different extremes on either end of the spectrum. In Scenario E, the enterprise has largely transitioned to IPv6 in both its applications and networks. However, Scenario E shows that a few legacy IPv4-based applications may still be found in the enterprise. On the other hand, Scenario J shows an enterprise that has begun its transition in a very disjointed manner and, in which IPv6-based applications and network segments are relatively rare.
场景E-J代表了过渡情况，其中企业必须继续互操作同一应用程序的基于IPv4和IPv6的实例化。此外，这些场景表明，企业尚未在其所有组织和/或服务提供商网络中完成向IPv6的过渡。相反，它在通信应用程序之间维护各种异构网段。情景E和J代表了频谱两端截然不同的极端情况。在场景E中，企业在其应用程序和网络中已基本过渡到IPv6。但是，场景E显示，在企业中仍然可以找到一些基于IPv4的遗留应用程序。另一方面，场景J显示了一个企业以一种非常不连贯的方式开始了转型，其中基于IPv6的应用程序和网段相对较少。
In this section, we address Scenario 1 as described in Section 3.1 of [BSCN]. The scenario, assumptions, and requirements are driven from the [BSCN] text. This analysis further corresponds to Scenario A in Section 3 above (although Scenario A shows a transitional situation wherein the enterprise has one network segment still lagging on transition to Dual-IP).
在本节中，我们将介绍[BSCN]第3.1节中描述的场景1。场景、假设和需求由[BSCN]文本驱动。该分析进一步对应于上文第3节中的场景A（尽管场景A显示了一种过渡情况，即企业有一个网段在过渡到双IP时仍然滞后）。
Within these IPv6 deployment scenarios the enterprise network administrator would introduce IPv6 by enabling IPv6 on the wire (i.e., within the network infrastructure) in a structured fashion with the existing IPv4 infrastructure. In such scenarios, a number of the existing IPv4 routers (and thus subnets) will be made Dual-IP, such that communications can run over either protocol.
在这些IPv6部署场景中，企业网络管理员将通过在现有IPv4基础设施中以结构化方式启用有线IPv6（即在网络基础设施中）来引入IPv6。在这种情况下，许多现有的IPv4路由器（以及子网）将被设置为双IP，这样通信可以通过任一协议运行。
Nodes on the Dual-IP links may themselves be IPv4-only or IPv6- capable. The driver for deploying IPv6 on the wire may not be for immediate wide-scale usage of IPv6, but rather to prepare an existing IPv4 infrastructure to support IPv6-capable nodes. Thus, while IPv6 is not used, Dual-IP nodes exist, and the enterprise can be transitioned to IPv6 on demand.
双IP链路上的节点本身可能仅支持IPv4或支持IPv6。在线路上部署IPv6的驱动程序可能不是为了立即广泛使用IPv6，而是为了准备现有的IPv4基础设施来支持支持支持IPv6的节点。因此，虽然不使用IPv6，但存在双IP节点，企业可以根据需要转换为IPv6。
Analyzing this scenario against existing transition mechanisms for their applicability suggests a staged approach for IPv6 deployment in the enterprise.
根据现有转换机制的适用性分析此场景，建议在企业中分阶段部署IPv6。
Under these scenarios (as well as most others), the site administrator should formulate a staged plan for the introduction of a Dual-IP IPv6 network. We suggest that Section 7 of this document provides a good basis for such a plan.
在这些情况下（以及大多数其他情况下），站点管理员应制定引入双IP IPv6网络的分阶段计划。我们建议，本文件第7节为此类计划提供了良好的基础。
In an enterprise network, the administrator will generally seek to deploy IPv6 in a structured, controlled manner, such that IPv6 can be enabled on specific links at various stages of deployment. There may be a requirement that some links remain IPv4 only, or some that specifically should not have IPv6 connectivity (e.g., Scenario A of Table 1). There may also be a requirement that aggregatable global IPv6 addresses, assigned by the enterprise's upstream provider from the address space allocated to them by the Regional Internet Registries (RIRs), be assigned.
在企业网络中，管理员通常会寻求以结构化、受控的方式部署IPv6，以便在部署的各个阶段在特定链路上启用IPv6。可能要求某些链路仅保留IPv4，或者某些链路不应具有IPv6连接（例如，表1的场景a）。还可能需要分配可聚合的全局IPv6地址，该地址由企业的上游提供商从区域互联网注册中心（RIR）分配给它们的地址空间分配。
In this document, we do not discuss the deployment of Unique Local IPv6 Unicast Addresses [ULA] because the address type and scope selected is orthogonal to the Layer 3 analysis of this document.
在本文档中，我们不讨论唯一本地IPv6单播地址[ULA]的部署，因为所选的地址类型和范围与本文档的第3层分析正交。
A typical deployment would initially involve the establishment of a single "testbed" Dual-IP subnet at the enterprise site prior to wider deployment. Such a testbed not only allows the IPv6 capability of specific platforms and applications to be evaluated and verified, but also permits the steps in Sections 7.3 and 7.4 of this document to be undertaken without (potential) adverse impact on the production elements of the enterprise.
典型的部署最初涉及在更广泛的部署之前在企业站点上建立一个“测试台”双IP子网。这种测试平台不仅允许评估和验证特定平台和应用程序的IPv6能力，还允许在不对企业生产要素（潜在）产生不利影响的情况下执行本文件第7.3节和第7.4节中的步骤。
Section 7.5 describes the stages for the widespread deployment in the enterprise, which could be undertaken after the basic building blocks for IPv6 deployment are in place.
第7.5节描述了企业中广泛部署的各个阶段，这些阶段可以在IPv6部署的基本构建块就位后进行。
A critical part of Dual-IP deployment is the selection of the IPv6- capable routing infrastructure to be implemented. The path taken will depend on whether the enterprise has existing Layer 2/3 switch/router equipment that has an IPv6 (routing) capability, or that can be upgraded to have such capability.
双IP部署的一个关键部分是选择要实现的支持IPv6的路由基础设施。所采用的路径将取决于企业是否拥有现有的具有IPv6（路由）功能的第2/3层交换机/路由器设备，或者可以升级为具有这种功能的设备。
In Section 4, we are not considering sparse IPv6 deployment; the goal of Dual-IP deployment is widespread use in the enterprise.
在第4节中，我们没有考虑稀疏IPv6部署；双IP部署的目标是在企业中广泛使用。
Where IPv6 routing capability exists within the infrastructure, the network administrator can enable IPv6 on the same physical hardware as the existing IPv4 service. Enabling both is the end-goal of any enterprise to support Dual-IP deployment, when the capability, performance, and robustness of the Dual-IP operational deployment has been verified.
如果基础架构中存在IPv6路由功能，则网络管理员可以在与现有IPv4服务相同的物理硬件上启用IPv6。当双IP操作部署的能力、性能和健壮性得到验证时，支持双IP部署是任何企业的最终目标。
Ideally, the IPv6 capability will span the entire enterprise, allowing deployment on any link or subnet. If not, techniques from Section 4.4 may be required.
理想情况下，IPv6功能将覆盖整个企业，允许在任何链路或子网上部署。如果没有，则可能需要第4.4节中的技术。
If the enterprise cannot provide IPv6 routing initially, there are alternative methods for transition. In this case, the enterprise administrator faces two basic choices, either to tunnel IPv6 over some or all of the existing IPv4 infrastructure, or to deploy a parallel IPv6 routing infrastructure providing IPv6 connectivity into existing IPv4 subnets.
如果企业最初无法提供IPv6路由，则有其他转换方法。在这种情况下，企业管理员面临两种基本选择，一种是在部分或全部现有IPv4基础设施上通过隧道传输IPv6，另一种是部署并行IPv6路由基础设施，为现有IPv4子网提供IPv6连接。
It may thus be the case that a node's IPv4 and IPv6 default routes to reach other links (subnets) are through different routing platforms.
因此，节点到达其他链路（子网）的IPv4和IPv6默认路由可能通过不同的路由平台。
Consider the situation where there exists IPv6 edge routers that are IPv6-capable, while others, and perhaps the enterprise backbone itself, are not IPv6-capable (Scenario B of Table 1). Tunneling, as described in [BCNF], would be established between the Dual-IP capable routers on the enterprise, thus "bypassing" existing non IPv6-capable routers and platforms.
考虑存在IPv6边缘路由器的情况，IPv6边缘路由器具有IPv6能力，而其他的企业骨干网本身可能不具有IPv6能力（表1的方案B）。如[BCNF]所述，隧道将在企业上具有双IP能力的路由器之间建立，从而“绕过”现有的不具备IPv6能力的路由器和平台。
In the widespread Dual-IP scenario, a more structured, manageable method is required, where the administrator has control of the deployment per-link and (ideally) long-term, aggregatable global IPv6 addressing is obtained, planned, and used from the outset.
在广泛使用的双IP场景中，需要一种更结构化、更易于管理的方法，其中管理员可以控制每条链路的部署，并且（理想情况下）从一开始就获得、规划和使用长期、可聚合的全局IPv6寻址。
Alternatively, the administrator may deploy a new, separate IPv6- capable router (or set of routers). It is quite possible that such a parallel infrastructure would be IPv6-dominant.
或者，管理员可以部署一个新的、独立的支持IPv6的路由器（或一组路由器）。这种并行基础设施很有可能成为IPv6的主导。
Such an approach would likely require additional hardware, but it has the advantage that the existing IPv4 routing platforms are not disturbed by the introduction of IPv6.
这种方法可能需要额外的硬件，但其优点是现有IPv4路由平台不会因IPv6的引入而受到干扰。
To distribute IPv6 to existing IPv4 enterprise subnets, either dedicated physical infrastructure can be employed or, if available, IEEE 802.1q VLANs could be used, as described in [VLAN]. The latter has the significant advantage of not requiring any additional physical cabling/wiring and also offers all the advantages of VLANs for the new Dual-IP environment. Many router platforms can tag multiple VLAN IDs on a single physical interface based on the subnet/link the packet is destined for; thus, multiple IPv6 links can be collapsed for delivery on a single (or small number of) physical IPv6 router interface(s) in the early stages of deployment.
要将IPv6分发到现有的IPv4企业子网，可以使用专用物理基础设施，或者可以使用IEEE 802.1q VLAN（如果可用），如[VLAN]中所述。后者的显著优点是不需要任何额外的物理布线/布线，并且还为新的双IP环境提供了VLAN的所有优势。许多路由器平台可以基于数据包目的地的子网/链路在单个物理接口上标记多个VLAN ID；因此，在部署的早期阶段，可以折叠多个IPv6链路，以便在单个（或少量）物理IPv6路由器接口上交付。
The parallel infrastructure should only be seen as an interim step towards full Dual-IP deployment on a unified infrastructure. The parallel infrastructure however allows all other aspects of the IPv6 enterprise services to be deployed, including IPv6 addressing, thus making the enterprise ready for that unifying step at a later date.
并行基础设施只应被视为在统一基础设施上实现完全双IP部署的过渡步骤。然而，并行基础设施允许部署IPv6企业服务的所有其他方面，包括IPv6寻址，从而使企业在以后为统一步骤做好准备。
When the enterprise's users are off-site, and using an ISP that does not support any native IPv6 service or IPv6 transition aids, the enterprise may consider deploying it's own remote IPv6 access support. Such remote support might for example be offered by deployment of an IPv6 Tunnel Broker [TBRK].
当企业的用户处于非现场状态，并且使用不支持任何本地IPv6服务或IPv6过渡辅助的ISP时，企业可以考虑部署其自己的远程IPv6访问支持。例如，可以通过部署IPv6隧道代理[TBRK]来提供这种远程支持。
There are some issues associated with turning IPv6 on by default, including application connection delays, poor connectivity, and network insecurity, as discussed in [V6DEF]. The issues can be worked around or mitigated by following the advice in [V6DEF].
如[V6DEF]中所述，默认情况下打开IPv6存在一些相关问题，包括应用程序连接延迟、连接不良和网络不安全。通过遵循[V6DEF]中的建议，可以解决或缓解这些问题。
This section covers Scenario 2 as described in Section 3.1 of [BSCN]. This scenario assumes the requirements defined within the [BSCN] text.
本节介绍了[BSCN]第3.1节所述的场景2。此场景假设[BSCN]文本中定义的需求。
IPv6 deployment within the enterprise network, with an existing IPv4 infrastructure, could be motivated by mission-critical or business applications or services that require IPv6. In this case, the prerequisite is that only the nodes using those IPv6 applications need to be upgraded to be IPv6-capable. The routing infrastructure will not be upgraded to support IPv6, nor does the enterprise wish to deploy a parallel IPv6 routing infrastructure at this point, since this is an option in Section 4.
使用现有IPv4基础设施在企业网络中部署IPv6可能受到需要IPv6的任务关键型或业务应用程序或服务的推动。在这种情况下，前提是只有使用这些IPv6应用程序的节点需要升级为支持IPv6。路由基础设施不会升级以支持IPv6，企业也不希望在此时部署并行IPv6路由基础设施，因为这是第4节中的一个选项。
There is a need for end-to-end communication with IPv6, but the infrastructure only supports IPv4 routing. Thus, the only viable method for end-to-end communication with IPv6 is to tunnel the traffic over the existing IPv4 infrastructure as defined in this analysis document.
需要使用IPv6进行端到端通信，但基础架构仅支持IPv4路由。因此，与IPv6进行端到端通信的唯一可行方法是通过本分析文档中定义的现有IPv4基础设施对流量进行隧道传输。
The network team needs to decide which of the available transition tunneling mechanisms are the most efficient to deploy, so they can be used without disrupting the existing IPv4 infrastructure. Several conditions require analysis, as introduced in the following sub-sections.
网络团队需要决定哪种可用的转换隧道机制最适合部署，以便在不中断现有IPv4基础设施的情况下使用它们。以下小节介绍了需要分析的几种情况。
Let's assume the upstream provider has deployed some IPv6 services, either native IPv6 in its backbone or in the access network, or some combination of both (Scenario B of Table 1). In this case, the provider will likely also deploy one or more transition mechanisms to support their IPv6 subscribers. Obviously, the enterprise could decide to take advantage of those transition services offered from the Provider. However, this will usually mean that individual nodes in the network require their own IPv6-in-IPv4 tunnel. The end result is somewhat inefficient IPv6 intranetworks communication, because all IPv6 traffic must be forwarded by the enterprise's IPv4 infrastructure to the Tunnel Endpoint offered by the Provider. Nevertheless, this may be acceptable, particularly if the IPv6
让我们假设上游提供商已经部署了一些IPv6服务，要么在其主干网中部署了本机IPv6，要么在接入网络中部署了本机IPv6，要么部署了两者的组合（表1的场景B）。在这种情况下，提供商可能还会部署一个或多个转换机制来支持其IPv6订户。显然，企业可以决定利用提供者提供的这些过渡服务。然而，这通常意味着网络中的各个节点需要自己的IPv6-in-IPv4隧道。最终的结果是IPv6内部网络通信效率较低，因为企业的IPv4基础设施必须将所有IPv6通信转发到提供商提供的隧道端点。然而，这是可以接受的，特别是如果IPv6
applications do not require intranetworks communication at all -- for example, when an application's server is located outside of the enterprise network, or on other intranetworks of the same enterprise.
应用程序根本不需要内部网络通信——例如，当应用程序的服务器位于企业网络之外，或者位于同一企业的其他内部网络上时。
Alternatively, the enterprise could decide to deploy its own transition mechanism node, possibly collocating it adjacent to the border router that connects to the upstream Provider. In this case, intranetnetworks communication using this tunnel endpoint is also possible.
或者，企业可以决定部署自己的转换机制节点，可能将其与连接到上游提供商的边界路由器相邻。在这种情况下，也可以使用此隧道端点进行intranetnetworks通信。
If the number of nodes to be using IPv6 is low, the first option is to use statically configured tunnels. However, automatically configured tunnels may be preferable, especially if the number is higher.
如果要使用IPv6的节点数较低，则第一个选项是使用静态配置的隧道。然而，自动配置的隧道可能更可取，尤其是如果数量更高。
In this section we are covering Scenario 3 as described in Section 3.1 of [BSCN]. The scenario, assumptions, and requirements are driven from the [BSCN] text. Within this document, this situation is captured in Scenario C of Table 1.
在本节中，我们将介绍[BSCN]第3.1节中描述的场景3。场景、假设和需求由[BSCN]文本驱动。在本文档中，这种情况在表1的场景C中得到了描述。
Some enterprise networks may wish to employ an IPv6-dominant network deployment strategy. What this means essentially is that the network or specific sites within the enterprise network will transition to IPv6 using only IPv6 routing to transfer both IPv4 and IPv6 packets over the network, even though the network may be Dual-IP capable. IPv4 routing would not be turned on within an IPv6-dominant network, except if required to support edge IPv4 networks.
一些企业网络可能希望采用IPv6主导的网络部署策略。这本质上意味着，企业网络中的网络或特定站点将转换为IPv6，仅使用IPv6路由在网络上传输IPv4和IPv6数据包，即使网络可能具有双IP功能。IPv4路由不会在IPv6主导网络内打开，除非需要支持边缘IPv4网络。
Under this scenario, communications between IPv6 nodes will use IPv6. When IPv6-capable nodes in the IPv6-dominant network need to communicate with IPv4 nodes, the IPv6 nodes will use their Dual-IP implementation to tunnel IPv4 packets in IPv6 [V6TUN]. An edge router within the IPv6-dominant network will decapsulate the IPv4 packet and route to the path of the IPv4 node on the network. This permits Dual-IP layer nodes to communicate with legacy IPv4 nodes within an IPv6-dominant network.
在这种情况下，IPv6节点之间的通信将使用IPv6。当IPv6主导网络中支持IPv6的节点需要与IPv4节点通信时，IPv6节点将使用其双IP实现在IPv6[V6TUN]中对IPv4数据包进行隧道传输。IPv6主导网络内的边缘路由器将解除IPv4数据包的封装，并路由到网络上IPv4节点的路径。这允许双IP层节点与IPv6主导网络中的传统IPv4节点通信。
Scenarios E and F from Table 1 depict additional cases where an IPv6-dominant deployment strategy could be in place. In Scenario E, the entire network could be IPv6-dominant, but the Host OS 2 system is running an IPv4 application. In Scenario F, the Host OS 1 system network could be IPv6-dominant, but the rest of the networks are all IPv4.
表1中的场景E和F描述了IPv6主导部署策略可能到位的其他情况。在场景E中，整个网络可能以IPv6为主，但主机OS 2系统正在运行IPv4应用程序。在场景F中，主机OS 1系统网络可能以IPv6为主，但其余网络都是IPv4。
In each case, communicating with an IPv4 end host or over an IPv4 network requires that a transition point exist within the network to support that operation. Furthermore, the node in the IPv6-dominant network must acquire an IPv4 address (to interoperate with the IPv4 end host), and locate a tunnel endpoint on their network which permits the IPv4 packet to be tunneled to the next-hop IPv6 router and eventually to a destination Dual-IP router.
在每种情况下，与IPv4终端主机或通过IPv4网络进行通信都需要网络中存在一个转换点来支持该操作。此外，IPv6主导网络中的节点必须获取IPv4地址（以与IPv4终端主机互操作），并在其网络上定位隧道端点，从而允许将IPv4数据包通过隧道传输到下一跳IPv6路由器，并最终传输到目标双IP路由器。
While retaining interoperability with IPv4 is a noble goal for enterprise architects, it is an unfortunate fact that maintaining IPv4 services in an IPv6-dominant network slows and may even impede your ability to reap the maximum benefits of IPv6.
虽然保持与IPv4的互操作性是企业架构师的崇高目标，但不幸的是，在IPv6占主导地位的网络中维护IPv4服务会减慢速度，甚至可能会妨碍您获得IPv6最大好处的能力。
The decision whether or not to use an IPv6-dominant network deployment strategy is completely driven by the enterprise's business and operational objectives and guided by the enterprise's transition plan.
是否使用IPv6主导的网络部署策略的决策完全由企业的业务和运营目标驱动，并由企业的过渡计划指导。
In this section, we describe generic enterprise IPv6 deployment issues, applicable to the analysis in Sections 4-6 of this document.
在本节中，我们将介绍通用企业IPv6部署问题，适用于本文档第4-6节中的分析。
The enterprise network administrator will need to follow a staged plan for IPv6 deployment. What this means is that a strategic identification of the enterprise network must be performed for all points and components of the transition.
企业网络管理员需要遵循IPv6部署的分阶段计划。这意味着必须对过渡的所有点和组件执行企业网络的战略标识。
The considerations for the enterprise components are detailed in Section 3.2 of [BSCN]. We do not go into detail on all aspects of such components in this document. In this document, we focus on Layer 3 issues.
[BSCN]第3.2节详细介绍了企业组件的注意事项。在本文件中，我们不会详细介绍此类组件的所有方面。在本文档中，我们将重点讨论第3层问题。
The first steps for IPv6 deployment do not involve technical aspects per se; the enterprise needs to select an external IPv6 provider and obtain globally routable IPv6 address space from that provider.
IPv6部署的第一步本身不涉及技术方面；企业需要选择外部IPv6提供程序，并从该提供程序获取全局可路由的IPv6地址空间。
The enterprise service provider would typically be a topographically close IPv6 provider that is able to provide an IPv6 upstream link. It would be expected that the enterprise would use either native IPv6 upstream connectivity or, in its absence, a manually configured tunnel [BCNF] to the upstream provider.
企业服务提供商通常是一个能够提供IPv6上游链路的拓扑关系紧密的IPv6提供商。预计企业将使用本机IPv6上游连接，或者在没有本机IPv6上游连接的情况下，使用手动配置的隧道[BCNF]连接到上游提供商。
The enterprise will obtain global IPv6 address space from its selected upstream provider, as provider-assigned (PA) address space.
企业将从其选定的上游提供商处获得全局IPv6地址空间，作为提供商分配的（PA）地址空间。
The enterprise should receive at least a /48 allocation from its provider, as described in [ALLOC].
如[ALLOC]所述，企业应至少从其提供商处收到a/48分配。
Should an enterprise change their provider, a procedure for enterprise renumbering between providers is described in [RENUM].
如果一家企业更改了其提供商，则[RENUM]中描述了提供商之间的企业重新编号过程。
Most of these are discussed in Section 4 of [BSCN]. Here we comment on those aspects that we believe are in scope for this analysis document. Thus, we have not included network management, multihoming, multicast, or application transition analysis here; however, these aspects should be addressed in Stage 2.
[BSCN]第4节讨论了其中的大部分内容。在这里，我们对我们认为在本分析文件范围内的那些方面进行评论。因此，我们这里没有包括网络管理、多宿主、多播或应用程序转换分析；但是，这些方面应在第2阶段解决。
A site will need to formulate an IPv6 addressing plan, utilizing the globally aggregatable public IPv6 prefix allocated to it by its upstream connectivity provider.
站点需要制定IPv6寻址计划，利用其上游连接提供商分配给它的全球可聚合公共IPv6前缀。
In a Dual-IP deployment, the site will need to decide whether it wishes to deploy IPv6 links to be congruent with existing IPv4 subnets. In this case, nodes will fall into the same links or subnets for both protocols. Such a scheme could be followed, with IPv6 prefix allocations being made such that room for topological growth is provisioned (reducing the potential requirement for future renumbering due to restructuring).
在双IP部署中，站点需要决定是否希望部署IPv6链接以与现有IPv4子网一致。在这种情况下，节点将落入两个协议的相同链路或子网中。可以遵循这样的方案，分配IPv6前缀，以便为拓扑增长提供空间（减少未来因重组而重新编号的潜在需求）。
A beneficial property of IPv6 is that an administrator will not need to invest as much effort in address conservation. With IPv4, a site will likely allocate IPv4 subnets to be as small as possible for the number of hosts currently in the subnet (e.g., a /26 for 50 nodes) because IPv4 address conservation is required. This creates problems
IPv6的一个有益特性是管理员不需要在地址保护方面投入那么多精力。使用IPv4时，站点可能会将IPv4子网分配为与子网中当前主机数量尽可能小的子网（例如，a/26用于50个节点），因为需要IPv4地址保护。这就产生了问题
when the number of nodes on a subnet grows, larger IPv4 prefixes are then required, and potentially time-consuming and disruptive renumbering events will follow.
当子网上的节点数量增加时，就需要更大的IPv4前缀，随后可能会发生耗时且破坏性的重新编号事件。
With IPv6, a link can in effect have any number of nodes, allowing link growth without the need to adjust prefix allocations with the associated renumbering requirement. The size of the initial site allocation (currently recommended to be a /48) also is likely to allow room for site growth without a need to return to the connectivity provider to obtain more, potentially non-sequential, address space (as is the case for IPv4 today, with the associated paperwork and probable delays).
使用IPv6，链路实际上可以有任意数量的节点，从而允许链路增长，而无需根据相关的重新编号要求调整前缀分配。初始站点分配的大小（目前建议为a/48）也可能允许站点增长空间，而无需返回连接提供商以获得更多的、可能不连续的地址空间（如今天的IPv4，相关的文书工作和可能的延迟）。
At the time of writing, best practice in IPv6 site address planning is restricted due to limited wide-scale deployments. Administrators should allocate /64 size prefixes for subnets, and do so in a way that has scope for growth within a site. The site should utilize a plan that reserves space for topological growth in the site, given that its initial IPv6 prefix allocation (currently recommended to be a /48) is likely to include such room for growth. Also see "IPv6 Unicast Address Assignment" [UNAD].
在撰写本文时，由于大规模部署有限，IPv6站点地址规划的最佳实践受到限制。管理员应该为子网分配/64大小的前缀，并以一种在站点内有增长空间的方式进行分配。考虑到初始IPv6前缀分配（目前建议为a/48）可能包括此类增长空间，站点应利用为站点拓扑增长预留空间的计划。另请参见“IPv6单播地址分配”[UNAD]。
The enterprise site should deploy a DNS service that is capable of both serving IPv6 DNS records using the AAAA format [DNSV6R] and communicating over IPv6 transport.
企业站点应部署一个DNS服务，该服务能够使用AAAA格式[DNSV6R]为IPv6 DNS记录提供服务，并通过IPv6传输进行通信。
Specific IPv6 DNS issues are reported in [DNSOP6].
[DNSOP6]中报告了特定的IPv6 DNS问题。
The enterprise network will need to support methods for internal and external routing.
企业网络将需要支持内部和外部路由的方法。
For a single-homed single-site network, a static route to a single upstream provider may be sufficient, although the site may choose to use an exterior routing protocol, especially where it has multiple upstream providers.
对于单宿单站点网络，尽管站点可以选择使用外部路由协议，特别是在其具有多个上游提供商的情况下，但是到单个上游提供商的静态路由可能就足够了。
For internal routing, an appropriate interior routing protocol may be deployed. IPv6 routing protocols that can be used are as follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF], and RIPng [RIPng].
对于内部路由，可以部署适当的内部路由协议。可以使用的IPv6路由协议如下：BGP4+[BGP4]、IS-IS[ISIS]、OSPFv3[OSPF]和RIPng[RIPng]。
An enterprise network will have a number of tools available for the delegation and management of IPv4 addresses and other configuration information. These include manual configuration, NIS [NIS], and DHCP [DHCPv4].
企业网络将有许多工具可用于IPv4地址和其他配置信息的委派和管理。其中包括手动配置、NIS[NIS]和DHCP[DHCPv4]。
In an IPv6 enterprise, Stateless Address Autoconfiguration [CONF] may be used to configure a host with a global IPv6 address, a default router, and on-link prefix information.
在IPv6企业中，无状态地址自动配置[CONF]可用于配置具有全局IPv6地址、默认路由器和链路前缀信息的主机。
Where support for secure autoconfiguration is required, SEND [SEND] can be used. Readers should see the applicability statements to IPsec [IPSEC] within the SEND document.
如果需要支持安全自动配置，可以使用SEND[SEND]。读者应在发送文档中看到IPsec[IPsec]的适用性声明。
A stateless configured node wishing to gain other configuration information (e.g., DNS, NTP servers) will likely need a Stateful DHCPv6 [DHCPv6] service available.
希望获得其他配置信息（例如DNS、NTP服务器）的无状态配置节点可能需要可用的有状态DHCPv6[DHCPv6]服务。
For nodes configuring using DHCPv6, where DHCPv6 servers are offlink, a DHCPv6 Relay Agent function will be required. Where DHCPv4 and DHCPv6 service are deployed together, dual-stack considerations need to be made, as discussed within current work on DHCP dual-stack issues [DHDS].
对于使用DHCPv6进行配置的节点，如果DHCPv6服务器断开链接，则需要DHCPv6中继代理功能。如果同时部署DHCPv4和DHCPv6服务，则需要考虑双堆栈问题，如当前有关DHCP双堆栈问题的工作[DHD]中所述。
Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; there is support for DHCPv6 to assign privacy addresses to nodes in managed environments.
主机还可以生成或请求IPv6隐私地址[priv6]；支持DHCPv6为托管环境中的节点分配隐私地址。
When deploying IPv6 within a Dual-IP network, a site will need to implement its site security policy for IPv6-capable nodes as it does for IPv4-capable nodes. For example, a border firewall should be capable of filtering and controlling IPv6 traffic by enforcing the same policy as it already does for IPv4.
在双IP网络中部署IPv6时，站点将需要为支持IPv6的节点实施其站点安全策略，就像对支持IPv4的节点一样。例如，边界防火墙应该能够通过实施与IPv4相同的策略来过滤和控制IPv6流量。
However, a site will also need to review its security policy in light of IPv6-specific functionality that will be deployed in the site, e.g., Mobile IPv6, stateless autoconfiguration (and SEND), IPv6 Privacy Extensions, and end-to-end IPsec. In addition, a site will need to review the use of globally aggregatable public address space where, for IPv4, private addressing and NAT may have been used.
但是，站点还需要根据将在站点中部署的特定于IPv6的功能（例如，移动IPv6、无状态自动配置（和发送）、IPv6隐私扩展和端到端IPsec）来审查其安全策略。此外，站点将需要审查全球可聚合公共地址空间的使用情况，对于IPv4，可能使用了专用寻址和NAT。
An overview of how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT can be found in [NAP]. This describes how the perceived security with IPv4 NAT can be achieved and surpassed with IPv6, i.e., how IPv6
有关使用IPv6的网络体系结构保护（NAP）如何在不需要NAT的情况下提供相同或更多好处的概述，请参见[NAP]。这描述了IPv4 NAT的感知安全性是如何通过IPv6实现和超越的，即IPv6是如何实现和超越的
technology can be used to provide the market-perceived benefits of IPv4 NAT.
技术可用于提供IPv4 NAT的市场感知好处。
Where deployed, intrusion detection systems will need to be enhanced to check IPv6 transport both for known application layer attack patterns and for new potential IPv6 threats, e.g., excessive hop-by-hop headers or errant IPv6 header options.
如果部署了入侵检测系统，则需要对其进行增强，以检查IPv6传输是否存在已知的应用层攻击模式和新的潜在IPv6威胁，例如，过多的逐跳标头或错误的IPv6标头选项。
The deployment of specific transition mechanisms may also introduce threats, e.g., carrying IPv6 data tunneled in IPv4. The site security policy should embrace the transition mechanisms that are deployed.
部署特定转换机制也可能带来威胁，例如，在IPv4中传输IPv6数据隧道。站点安全策略应包含已部署的转换机制。
An overview of IPv6 security issues can be found in [V6SEC]. This includes discussion of issues specific to the IPv6 protocol, to transition mechanisms, and to IPv6 deployment itself.
有关IPv6安全问题的概述，请参见[V6SEC]。这包括对特定于IPv6协议、转换机制和IPv6部署本身的问题的讨论。
In addition, an enterprise should review all current host-based security requirements for their networks and verify support for IPv6.
此外，企业应审查其网络当前所有基于主机的安全要求，并验证对IPv6的支持。
With the basic building blocks of external connectivity, interior IPv6 routing, an IPv6 DNS service, and address allocation management in place, the IPv6 capability can be rolled out to the wider enterprise. This involves putting IPv6 on the wire in the desired links, and enabling applications and other services to begin using an IPv6 transport.
有了外部连接、内部IPv6路由、IPv6 DNS服务和地址分配管理的基本构建块，IPv6功能可以扩展到更广泛的企业。这包括将IPv6连接到所需链路中，并允许应用程序和其他服务开始使用IPv6传输。
In the Dual-IP deployment case, this means enabling IPv6 on existing IPv4 subnets. As described in Section 7.4.4, above, it is likely that IPv6 links will be congruent with IPv4 subnets because IPv4 subnets tend to be created for geographic, policy, or administrative reasons that would be IP version-independent.
在双IP部署情况下，这意味着在现有IPv4子网上启用IPv6。如上文第7.4.4节所述，IPv6链路很可能与IPv4子网一致，因为IPv4子网往往是出于地理、政策或管理原因创建的，这些原因与IP版本无关。
While the use of IPv6 by some applications can be administratively controlled (e.g., in the case of open source software by compiling the application without IPv6 support enabled), the use of IPv6 transport, and preference over IPv4 transport, will vary per application based on the developer/author's implementation.
虽然某些应用程序对IPv6的使用可以进行管理控制（例如，在开源软件的情况下，通过编译未启用IPv6支持的应用程序），但IPv6传输的使用以及相对于IPv4传输的偏好将根据开发人员/作者的实现而有所不同。
A Dual-IP deployment will often be made by sites wishing to support use of IPv6 within a site, even if IPv6 transport is not preferred by all applications. Putting support for IPv6 in all site infrastructure (DNS, email transport, etc.) allows IPv6 usage to be phased in over time. As nodes become IPv6 capable, and applications and services IPv6 enabled, the IPv6 capable infrastructure can be leveraged. For most networks, Dual-IP will be at the very least a
希望在站点内支持IPv6使用的站点通常会进行双IP部署，即使并非所有应用程序都首选IPv6传输。在所有站点基础设施（DNS、电子邮件传输等）中提供对IPv6的支持，可以随着时间的推移逐步使用IPv6。随着节点支持IPv6，应用程序和服务支持IPv6，可以利用支持IPv6的基础架构。对于大多数网络，双IP至少是一个
medium-term transition towards an IPv6-dominant future. However, the introduction of IPv6 support, with the potential benefits of globally aggregatable public address usage (with [NAP]) and other new IPv6 capabilities, can bring more immediate benefits for the site.
向IPv6主导未来的中期过渡。但是，IPv6支持的引入，以及全球可聚合公共广播使用（使用[NAP]）和其他新IPv6功能的潜在好处，可以为站点带来更直接的好处。
This section will provide general guidance for the use of specific transition mechanisms which in turn can be used by the enterprise to support the enterprise matrix notional networks (rows) in Section 3, and within the context of the analysis discussed in Sections 4, 5, and 6.
本节将为具体过渡机制的使用提供一般指导，企业可以使用这些机制来支持第3节中的企业矩阵概念网络（ROW），并在第4、5和6节中讨论的分析背景下使用。
Table 1 provides a number of common scenarios that an enterprise architect might encounter as they consider how and where they should consider deploying transition mechanisms to support the network transition to IPv6. Selecting the most appropriate mechanism for each scenario is more of an art than a science and consequently making recommendations against each of the ten scenarios would be simply fodder for sharpshooters touting their favored product. However we can provide some high-level guidance that should benefit the architect's decision-making process.
表1提供了企业架构师可能遇到的许多常见场景，因为他们考虑如何以及在何处考虑部署过渡机制来支持向IPv6的网络过渡。为每个场景选择最合适的机制与其说是一门科学，不如说是一门艺术。因此，针对十个场景中的每一个场景提出建议，只不过是推销他们喜爱的产品的神枪手的素材。但是，我们可以提供一些高级指导，这些指导应该有利于架构师的决策过程。
Mapping your specific situation into one of the ten scenarios of Table 1 is far less important than recognizing the critical touchpoints within the enterprise networks where incompatible networks interface. Unless a transition mechanism is being offered by the enterprise as a service, it is at these touchpoints that a mechanism must be considered.
将您的具体情况映射到表1的十个场景之一远不如识别企业网络中不兼容网络接口的关键接触点重要。除非企业将转换机制作为服务提供，否则必须在这些接触点上考虑机制。
A quick review of Table 1 reveals that the ten scenarios can be boiled down to variations of four major themes. The simplest, but also most favored (due to its flexibility), is widespread Dual-IP with compatible hosts at either end. This situation is illustrated in Scenario A, and transition mechanism considerations have already been described in some detail in Section 4.
对表1的快速回顾表明，这十种情景可以归结为四个主要主题的变化。最简单但也是最受欢迎的（由于其灵活性），是两端都有兼容主机的广泛的双IP。场景A中说明了这种情况，第4节中已经详细描述了过渡机制的考虑因素。
In the second common theme (depicted in Scenarios B-D of Table 1), the enterprise is comprised of compatible hosts, with one or more incompatible network touchpoints in between. As described in Section 4.2.2.1, tunneling can be used to "bypass" the incompatible network segments. One tunneling option, manually configured tunnels [BCNF] could be used by the enterprise, but as the name implies, this mechanism provides no automated tunnel configuration.
在第二个公共主题（如表1的场景B-D所示）中，企业由兼容主机组成，其间有一个或多个不兼容的网络接触点。如第4.2.2.1节所述，隧道可用于“绕过”不兼容的网段。企业可以使用一种隧道选项，即手动配置的隧道[BCNF]，但顾名思义，这种机制不提供自动隧道配置。
"Connection of IPv6 Domains via IPv4 Clouds" [6TO4] can be used to support enterprises that do not have an assigned IPv6 prefix address.
“通过IPv4云连接IPv6域”[6TO4]可用于支持没有指定IPv6前缀地址的企业。
Identifying the responsible device to perform the tunneling is driven by the position of the incompatible touchpoint. If a local network is incompatible, then host tunneling is appropriate. If the backbone (provider) network is incompatible, then gateway-to-gateway tunneling might be a better choice. By working to ensure tunnel endpoints are always configured at Dual-IP devices, end-to-end communication or services (IPv4 or IPv6) can be preserved.
识别负责执行隧道的设备由不兼容接触点的位置驱动。如果本地网络不兼容，则主机隧道是合适的。如果主干（提供商）网络不兼容，那么网关到网关隧道可能是更好的选择。通过努力确保始终在双IP设备上配置隧道端点，可以保留端到端通信或服务（IPv4或IPv6）。
Readers should review the current work regarding tunnels within the IETF Softwire working group and problem statement [SOFTW].
读者应回顾IETF软线工作组和问题陈述[SOFTW]中有关隧道的当前工作。
Having IPv6 applications on a Dual-IP host on a v4-only network requires some form of tunneling. Where configured tunnels are not sufficient, a more automatic solution may be appropriate. Available solutions include the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [ISTP] or Teredo [TRDO] to tunnel to a v6 end service. ISATAP [ISTP] can be used to provide end-node IPv6 connectivity from nodes on an isolated IPv4 network, through the use of automatic tunneling of IPv6 in IPv4. Teredo [TRDO] can be used when the enterprise network is behind a NAT.
在仅v4网络上的双IP主机上安装IPv6应用程序需要某种形式的隧道。如果配置的隧道不够，则可能需要更自动化的解决方案。可用的解决方案包括站点内自动隧道寻址协议（ISATAP）[ISTP]或Teredo[TRDO]以隧道到v6终端服务。ISATAP[ISTP]可通过在IPv4中使用IPv6的自动隧道，从孤立IPv4网络上的节点提供端节点IPv6连接。Teredo[TRDO]可在企业网络位于NAT后面时使用。
Enterprise architects should consider providing a Tunnel Broker [TBRK] [TSPB] as a cost-effective service to local users or applications. Tunnel Brokers can be used to provide tunnel setup for an enterprise using manually configured tunnels and 6TO4 [6TO4]. Tunnel Brokers can automate the use of tunnels across an enterprise deploying IPv6.
企业架构师应该考虑将隧道代理[TBRK] [TSPB]提供给本地用户或应用程序的具有成本效益的服务。隧道代理可用于使用手动配置的隧道和6TO4[6TO4]为企业提供隧道设置。隧道代理可以跨部署IPv6的企业自动使用隧道。
Later in the transition process, after the enterprise has transitioned to a predominately IPv6 infrastructure, the architect will need to determine a network transition strategy to tunnel IPv4 within IPv6 [V6TUN] across IPv6-dominant links, or the enterprise Intranet. Or in the case of early deployment of IPv6-dominant networks, the architect will need to address this from the beginning of the required transition planning.
在过渡过程的后期，在企业过渡到以IPv6为主的基础设施之后，架构师需要确定一种网络过渡策略，以便在IPv6[V6TUN]内跨IPv6主要链路或企业内部网隧道IPv4。或者，在早期部署IPv6主导网络的情况下，架构师需要从所需的过渡规划开始解决这一问题。
Having recognized incompatible network touchpoints, it is also incumbent on the architect to identify application incompatibilities. During the transition period, particularly for large enterprises, it is to be expected that an application hosted at one location may lead (or lag) the IPv6-compatibility of its peer (or server) at some other location.
在识别了不兼容的网络接触点之后，架构师也有责任识别应用程序不兼容。在过渡期内，特别是对于大型企业，可以预期，托管在一个位置的应用程序可能会导致（或滞后）其他位置的对等（或服务器）的IPv6兼容性。
This leads us to the third theme (represented by Scenarios E and G): incompatible applications communicating across a homogenous network. Translation is an obvious solution, but not recommended except for legacy devices that are at the network edge and cannot or never will be upgraded to IPv6. A more scalable solution would be to use an Application Layer Gateway (ALG) between the incompatible hosts.
这就引出了第三个主题（由场景E和G表示）：跨同质网络通信的不兼容应用程序。转换是一个显而易见的解决方案，但不推荐使用，但位于网络边缘且无法或永远不会升级到IPv6的传统设备除外。更具可扩展性的解决方案是在不兼容的主机之间使用应用层网关（ALG）。
Inevitably, during the course of transitioning a large enterprise to IPv6, the architect will be faced with both incompatible hosts and simultaneously (at different parts of the enterprise) incompatible networks. These highly complex situations represent the fourth common theme in Table 1 (specifically depicted by Scenarios F, H, I, and J). Maintaining IP interoperability in these situations requires additional planning and may require multiple or even nested use of diverse transition mechanisms. For example, an ALG collocated with the application server may be required to service both IPv4 and IPv6 data streams that are simultaneously tunneled through incompatible network segment(s).
不可避免地，在将大型企业过渡到IPv6的过程中，架构师将同时面临不兼容的主机和（在企业的不同部分）不兼容的网络。这些高度复杂的情况代表了表1中的第四个共同主题（具体由场景F、H、I和J描述）。在这些情况下维护IP互操作性需要额外的规划，可能需要多次甚至嵌套地使用不同的转换机制。例如，可能需要与应用服务器并置的ALG来为同时通过不兼容网段进行隧道传输的IPv4和IPv6数据流提供服务。
Security considerations for IPv6 deployment in a Dual-IP environment are discussed above in Section 7.4.5, where external references to overview documents [V6SEC] [NAP] are also included.
上文第7.4.5节讨论了在双IP环境中部署IPv6的安全注意事项，其中还包括对概述文档[V6SEC][NAP]的外部参考。
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[CONF]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 24621998年12月。
[DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[DHCPv6]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 33151003年7月。
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[6TO4]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[BSCN] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[BSCN]Bound，J.，Ed.“IPv6企业网络场景”，RFC 4057，2005年6月。
[TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[TRDO]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[ISTP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005.
[ISTP]Templin，F.，Gleeson，T.，Talwar，M.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 4214，2005年10月。
[V6TUN] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[V6TUN]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[TBRK] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[TBRK]Durand，A.，Fasano，P.，Guardini，I.，和D.Lento，“IPv6隧道代理”，RFC 3053，2001年1月。
[ALLOC] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[ALLOC]IAB和IESG，“IAB/IESG对站点IPv6地址分配的建议”，RFC3177，2001年9月。
[NATPT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[NATPT]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[UMAN] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004.
[UMAN]Huitema，C.，Austein，R.，Satapati，S.，和R.van der Pol，“非托管网络IPv6过渡机制的评估”，RFC 3904，2004年9月。
[ISPA] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[ISPA]Lind，M.，Ksinant，V.，Park，S.，Baudot，A.，和P.Savola，“将IPv6引入ISP网络的场景和分析”，RFC 40292005年3月。
[3GPA] Wiljakka, J., Ed., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[3GPA]Wiljakka，J.，Ed.，“第三代合作伙伴计划（3GPP）网络中IPv6过渡的分析”，RFC 4215，2005年10月。
[OSPF] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[OSPF]Coltun，R.，Ferguson，D.，和J.Moy，“IPv6的OSPF”，RFC 27401999年12月。
[BGP4] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[BGP4]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[ISIS] Oran, D., Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990.
[ISIS]Oran，D.，编辑，“OSI IS-IS域内路由协议”，RFC 1142，1990年2月。
[RIPng] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RIPng]Malkin，G.和R.Minnear，“IPv6的RIPng”，RFC 20801997年1月。
[APPS] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[应用]Shin，M-K.，Ed.，Hong，Y-G.，Hagino，J.，Savola，P.，和E.Castro，“IPv6过渡的应用方面”，RFC 4038，2005年3月。
[RENUM] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RENUM]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[BCNF] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[BCNF]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[ULA]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[DNSOP6] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006.
[DNSOP6]Durand，A.，Ihren，J.，和P.Savola，“IPv6 DNS的操作注意事项和问题”，RFC 4472，2006年4月。
[DNSV6R] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[DNSV6R]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[NIS] Kalusivalingam, V., "Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[NIS]Kalusialingam，V.，“IPv6动态主机配置协议（DHCPv6）的网络信息服务（NIS）配置选项”，RFC 3898，2004年10月。
[DHCPv4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCPv4]Droms，R.，“动态主机配置协议”，RFC 21311997年3月。
[IPSEC] Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[IPSEC]Eastlake 3rd，D.，“封装安全有效载荷（ESP）和认证头（AH）的加密算法实现要求”，RFC 4305，2005年12月。
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[发送]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（发送）”，RFC 39712005年3月。
[PRIVv6] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[Priv6]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[TSPB] Blanchet, M., and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP", Work in Progress, August 2005.
[TSPB]Blanchet，M.和F.Parent，“具有隧道设置协议（TSP）的IPv6隧道代理”，正在进行的工作，2005年8月。
[V6SEC] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", Work in Progress, October 2006.
[V6SEC]Davies，E.，Krishnan，S.，和P.Savola，“IPv6过渡/共存安全考虑”，正在进行的工作，2006年10月。
[NAP] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", Work in Progress, January 2007.
[NAP]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，正在进行的工作，2007年1月。
[CAMP] Chown, T., "IPv6 Campus Transition Scenario Description and Analysis", Work in Progress, March 2007.
[CAMP]Chown，T.，“IPv6校园过渡场景描述和分析”，正在进行的工作，2007年3月。
[DHDS] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, May 2006.
[DHDS]Chown，T.，Venaas，S.，和C.Strauf，“动态主机配置协议（DHCP）：IPv4和IPv6双栈问题”，RFC 4477，2006年5月。
[UNAD] Van de Velde, G., Popoviciu, C., and T. Chown, "IPv6 Unicast Address Assignment", Work in Progress, March 2007.
[UNAD]Van de Velde，G.，Popoviciu，C.，和T.Chown，“IPv6单播地址分配”，正在进行的工作，2007年3月。
[VLAN] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks", RFC 4554, June 2006.
[VLAN]Chown，T.“在企业网络中使用VLAN实现IPv4-IPv6共存”，RFC 45542006年6月。
[V6DEF] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", Work in Progress, January 2006.
[V6DEF]Roy，S.，Durand，A.，和J.Paugh，“基于链路假设的IPv6邻居发现被认为是有害的”，正在进行的工作，2006年1月。
[SOFTW] Dawkins, S., Ed., "Softwire Problem Statement", Work in Progress, March 2007.
[SOFTW]Dawkins，S.，Ed.，“软线问题陈述”，正在进行的工作，2007年3月。
The authors would like to acknowledge contributions from the following: IETF v6ops Working Group members, Fred Baker, Pekka Savola, and Jordi Palet
作者要感谢以下方面的贡献：IETF v6ops工作组成员、Fred Baker、Pekka Savola和Jordi Palet
This appendix first describes different scenarios for the introduction of IPv6 into a crisis management network for emergency services, defense, or security forces that are currently running IPv4 service. Then, the scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified.
本附录首先描述了将IPv6引入危机管理网络的不同场景，用于当前运行IPv4服务的应急服务、国防或安全部队。然后，分析了引入IPv6的场景，并评估了已定义的转换机制的相关性。还确定了已知的挑战。
When a crisis management enterprise deploys IPv6, its goal is to provide IPv6 connectivity on its institutional fixed networks and on the mobile wireless services that are deployed to a crisis area. The new IPv6 service must be added to an already existing IPv4 service, the introduction of IPv6 must not interrupt this IPv4 service, and the IPv6 services must be interoperable with existing IPv4 services.
危机管理企业部署IPv6时，其目标是在其机构固定网络和部署到危机地区的移动无线服务上提供IPv6连接。新的IPv6服务必须添加到现有的IPv4服务中，IPv6的引入不得中断此IPv4服务，并且IPv6服务必须可与现有IPv4服务互操作。
Crisis management enterprises accessing IPv4 service across mobile ground networks, airborne networks, and satellites will find different ways to add IPv6 to this service based on their network architecture, funding, and institutional goals. This document discusses a small set of scenarios representing the architectures for IPv6 expected to be dominant in crisis management networks during the next decade. This document evaluates the relevance of the existing transition mechanisms in the context of these deployment scenarios, and points out the lack of essential functionality within these methods for a provider to support IPv6 services for these scenarios.
跨移动地面网络、机载网络和卫星访问IPv4服务的危机管理企业将根据其网络架构、资金和机构目标，找到不同的方式将IPv6添加到该服务中。本文档讨论了一小部分场景，这些场景代表了预计在未来十年内将在危机管理网络中占据主导地位的IPv6体系结构。本文档评估了现有转换机制在这些部署场景中的相关性，并指出这些方法中缺少供应商支持这些场景中IPv6服务的基本功能。
The document focuses on services that include both IPv6 and IPv4 and does cover issues surrounding accessing IPv4 services across IPv6- only networks. It is outside the scope of this document to describe detailed implementation plans for IPv6 in defense networks.
本文档重点介绍同时包含IPv6和IPv4的服务，并涵盖了跨仅IPv6网络访问IPv4服务的相关问题。描述IPv6在国防网络中的详细实施计划超出了本文件的范围。
Scenario 1: Limited IPv6 Deployment Network
场景1：有限的IPv6部署网络
Sparse IPv6 dual-stack deployment in an existing IPv4 network infrastructure. Enterprise with an existing IPv4 network wants to deploy a set of particular IPv6 "applications" and have some ability to interoperate with other institutions that are using IPv6 services. The IPv6 deployment is limited to the minimum required to operate this set of applications.
现有IPv4网络基础架构中的稀疏IPv6双堆栈部署。拥有现有IPv4网络的企业希望部署一组特定的IPv6“应用程序”，并能够与使用IPv6服务的其他机构进行互操作。IPv6部署仅限于操作这组应用程序所需的最低限度。
Assumptions: IPv6 software/hardware components for the application are available, and platforms for the application are IPv6 capable.
假设：应用程序的IPv6软件/硬件组件可用，且应用程序的平台支持IPv6。
Requirements: Do not disrupt IPv4 infrastructure.
要求：不要中断IPv4基础结构。
Scenario 2: Dual-Stack Network
场景2：双栈网络
Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable hosts and network infrastructure. Enterprise with an existing IPv4 network wants to deploy IPv6 in conjunction with their IPv4 network in order to take advantage of emerging IPv6 network-centric capabilities and to be interoperable with other agencies, international partners, and commercial enterprises that are deploying an IPv6 architecture.
支持IPv4和IPv6的主机和网络基础架构的大规模/全面双栈部署。具有现有IPv4网络的企业希望将IPv6与其IPv4网络一起部署，以利用新兴的IPv6网络中心功能，并与正在部署IPv6体系结构的其他机构、国际合作伙伴和商业企业进行互操作。
Assumptions: The IPv4 network infrastructure used has an equivalent capability in IPv6.
假设：所使用的IPv4网络基础设施在IPv6中具有同等的功能。
Requirements: Do not disrupt existing IPv4 network infrastructure with IPv6. IPv6 should be equivalent or "better" than the network infrastructure in IPv4. It may not be feasible to deploy IPv6 on all parts of the network immediately. Dual-stacked defense enterprise network must be interoperable with both IPv4 and IPv6 networks and applications.
要求：不要使用IPv6中断现有IPv4网络基础架构。IPv6应该与IPv4中的网络基础设施相当或“更好”。在网络的所有部分立即部署IPv6可能是不可行的。双堆叠防御企业网络必须能够与IPv4和IPv6网络及应用程序互操作。
Scenario 3: IPv6-Dominant Network
场景3：IPv6主导网络
Enterprise has some limited IPv4-capable/only nodes/applications needing to communicate over the IPv6 infrastructure. Crisis management enterprise re-structuring an existing network, decides to pursue aggressive IPv6 transition as an enabler for network-centric services and wants to run some native IPv6-only networks to eliminate cost/complexity of supporting a dual stack. Some legacy IPv4 capable nodes/applications within the enterprise will have slow technical refresh/replacement paths and will need to communicate over the IPv6 dominant infrastructure for years until they are replaced. The IPv6-dominant enterprise network will need to be interoperable with its own legacy networks, commercial networks, and the legacy networks of similar organizations that will remain IPv4-dominant during a long transition period. Reserve units, contractors, other agencies, and international partners may need IPv4 service across this enterprise's IPv6-dominant backbone.
企业有一些有限的支持IPv4的/仅限于需要通过IPv6基础架构进行通信的节点/应用程序。危机管理企业重组现有网络，决定寻求积极的IPv6过渡，作为以网络为中心的服务的促成因素，并希望运行一些仅限IPv6的本机网络，以消除支持双堆栈的成本/复杂性。企业内某些支持IPv4的旧式节点/应用程序的技术更新/替换路径较慢，需要在IPv6主导基础架构上通信数年，直到被替换为止。IPv6主导的企业网络将需要与自己的传统网络、商业网络以及类似组织的传统网络进行互操作，这些组织将在较长的过渡期内保持IPv4主导地位。后备部队、承包商、其他机构和国际合作伙伴可能需要跨此企业的IPv6主干网提供IPv4服务。
Assumptions: Required IPv6 network infrastructure is available, or available over some defined timeline, supporting the aggressive transition plan.
假设：所需的IPv6网络基础设施可用，或在某些规定的时间内可用，支持积极的过渡计划。
Requirements: Reduce operation and maintenance requirements and increase net-centricity through aggressive IPv6 transition. Interoperation and coexistence with legacy IPv4 networks and applications is required. Legacy IPv4 nodes/applications/networks will need to be able to operate across the IPv6 backbone and need to
要求：通过积极的IPv6过渡，降低操作和维护要求，提高网络中心性。需要与旧式IPv4网络和应用程序进行互操作和共存。旧式IPv4节点/应用程序/网络需要能够跨IPv6主干网运行，并且需要
be able to interoperate with the IPv6-dominant network's nodes/applications.
能够与IPv6主导网络的节点/应用程序进行互操作。
A generic network topology for crisis management reflects the various ways a crisis management network can connect customers through their network infrastructure. Because the institution's existing wired and fixed-site wireless infrastructure can be destroyed or unavailable in a crisis, the crisis management network must be able to deploy its own mobile wireless network or connect through external wired and wireless networks provided by ISPs or partner organizations. This infrastructure lets us divide the basic areas for IPv4/IPv6 interoperability into three main areas: the customer applications, the local network, and the network backbone.
用于危机管理的通用网络拓扑反映了危机管理网络通过其网络基础设施连接客户的各种方式。由于机构现有的有线和固定站点无线基础设施可能在危机中被破坏或不可用，因此危机管理网络必须能够部署自己的移动无线网络或通过ISP或合作伙伴组织提供的外部有线和无线网络进行连接。该基础架构使我们能够将IPv4/IPv6互操作性的基本领域划分为三个主要领域：客户应用程序、本地网络和网络主干。
The basic components in a crisis management network are depicted in Figure 1.
图1描述了危机管理网络中的基本组件。
------------ ---------- ---- Wired Connection
| Network and| | | .... Wireless Connection
| Service |--| Backbone |
| Operation | | |
------------ ----------
/ | ---------------------
/ : _|Connection to |
/ : |Commercial Internet |
/ : ---------------------
Network Backbone
-------------- /------|-------------|--------------------
---------- / ---------- ----------
| Home |/ | Wireless | |External |.............
| Base | | Mobile | |Untrusted |+--------- :
| Network | | Network | |Network | | :
---------- ---------- ---------- | :
| : : | :
Local Network
-----:------------:-----------------------------------
Customer Applications
| : : | :
+--------+ +--------+ +--------+ | :
| | | | | | | :
|Customer| |Customer| |Customer|+----------- :
| | | | | |..............
+--------+ +--------+ +--------+
------------ ---------- ---- Wired Connection
| Network and| | | .... Wireless Connection
| Service |--| Backbone |
| Operation | | |
------------ ----------
/ | ---------------------
/ : _|Connection to |
/ : |Commercial Internet |
/ : ---------------------
Network Backbone
-------------- /------|-------------|--------------------
---------- / ---------- ----------
| Home |/ | Wireless | |External |.............
| Base | | Mobile | |Untrusted |+--------- :
| Network | | Network | |Network | | :
---------- ---------- ---------- | :
| : : | :
Local Network
-----:------------:-----------------------------------
Customer Applications
| : : | :
+--------+ +--------+ +--------+ | :
| | | | | | | :
|Customer| |Customer| |Customer|+----------- :
| | | | | |..............
+--------+ +--------+ +--------+
Figure 1: Crisis Management Network Topology.
图1：危机管理网络拓扑。
The stages are derived from the generic description of scenarios for crisis management networks in Section 2. Combinations of different building blocks that constitute a crisis network environment lead to a number of scenarios from which the network engineers can choose. The scenarios most relevant to this document are those that maximize the network's ability to offer IPv6 to its customers in the most efficient and feasible way. In the first three stages, the goal is to offer both IPv4 and IPv6 to the customer, and it is assumed that in the distant future, all IPv4 services will be eventually switched to IPv6. This document will cover engineering the first four stages.
这些阶段源自第2节中对危机管理网络场景的一般描述。构成危机网络环境的不同构建块的组合会导致许多场景，网络工程师可以从中进行选择。与本文档最相关的场景是那些以最有效和可行的方式最大化网络向其客户提供IPv6的能力的场景。在前三个阶段，目标是向客户提供IPv4和IPv6，并假设在遥远的将来，所有IPv4服务最终都将切换到IPv6。本文件将涵盖前四个阶段的工程设计。
The four most probable stages are:
最可能的四个阶段是：
o Stage 1 Limited Launch o Stage 2 Dual-Stack Dominance o Stage 3 IPv6 Dominance o Stage 4 IPv6 Transition Complete
o 第1阶段有限启动o第2阶段双栈优势o第3阶段IPv6优势o第4阶段IPv6过渡完成
Generally, a crisis management network is able to entirely upgrade a current IPv4 network to provide IPv6 services via a dual-stack network in Stage 2 and then slowly progress to Stages 3 and 4 as indicated in Figure 2. During Stage 2, when most applications are IPv6 dominant, operational and maintenance costs can be reduced on some networks by moving to Stage 3 and running backbone networks entirely on IPv6, while adding IPv4 backwards compatibility via v4 in v6 tunneling or translation mechanisms to the existing configuration from Stage 2. When designing a new network, if a new IPv6-only service is required, it can be implemented at a lower cost by jumping directly to Stage 3/4 if there are only limited or no legacy concerns.
通常，危机管理网络能够在第2阶段完全升级当前IPv4网络，通过双栈网络提供IPv6服务，然后缓慢进入第3和第4阶段，如图2所示。在第2阶段，当大多数应用程序以IPv6为主时，可以通过转移到第3阶段并完全在IPv6上运行主干网络来降低某些网络上的运营和维护成本，同时通过v6中的v4隧道或转换机制将IPv4向后兼容性添加到第2阶段的现有配置中。在设计新网络时，如果只需要新的IPv6服务，则可以通过直接跳到第3/4阶段（如果只存在有限的遗留问题或没有遗留问题）以较低的成本实现。
Stage 1: Limited Launch
第一阶段：有限发射
The first stage begins with an IPv4-only network and IPv4 customers. This is the most common case today and the natural starting point for the introduction of IPv6. During this stage, the enterprise begins to connect individual IPv6 applications run on dual-stacked hosts through host-based tunneling using Tunnel Broker, ISATAP, or Teredo. Some early adopter networks are created for pilot studies and networked together through configured tunnels and 6to4.
第一阶段从仅IPv4网络和IPv4客户开始。这是当今最常见的情况，也是引入IPv6的自然起点。在此阶段，企业开始使用隧道代理、ISATAP或Teredo通过基于主机的隧道连接在双堆叠主机上运行的单个IPv6应用程序。一些早期采用者网络是为试点研究而创建的，并通过配置的隧道和6to4网络连接在一起。
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 crisis management enterprise will also need to establish IPv6 connectivity between its home base networks and mobile wireless networks over its backbone. It will need to negotiate IPv6 service with its service providers and with peer organizations; it is of utmost importance to require IPv6 capability or an upgrade plan when negotiating purchases of network applications and infrastructure. In the short term, network connections, especially legacy wireless networks that cannot provide IPv6 services, can provide IPv6 services through the use of tunnels. However, the longer-term goal must be requiring and obtaining IPv6 native connectivity from the transit networks. Otherwise, the quality of IPv6 connectivity will likely be poor and the transition to Stage 2 will be delayed.
危机管理企业还需要通过主干网在其家庭基础网络和移动无线网络之间建立IPv6连接。与It服务提供商协商IPv6服务需求；在谈判购买网络应用程序和基础设施时，要求具备IPv6功能或升级计划至关重要。在短期内，网络连接，特别是不能提供IPv6服务的传统无线网络，可以通过使用隧道提供IPv6服务。但是，长期目标必须是要求并从传输网络获得IPv6本机连接。否则，IPv6连接的质量可能会很差，向第2阶段的过渡将延迟。
Stage 2: Dual-Stack Dominance
第二阶段：双堆栈优势
Stage 2 occurs when most applications, local networks, and network backbones become dual-stacked so that native IPv6 connections are enabled. At this point there is a mix of IPv4 and IPv6 applications and services in use across the enterprise. The enterprise may be made IPv6-capable through either software upgrades, hardware upgrades, or a combination of both. Generally IPv6 is added during normal technical refresh as the enterprise buys new equipment that is IPv6 ready.
第2阶段发生在大多数应用程序、本地网络和网络主干成为双堆叠以便启用本机IPv6连接时。目前，整个企业都在使用IPv4和IPv6应用程序和服务。企业可以通过软件升级、硬件升级或两者的结合来实现IPv6功能。通常情况下，IPv6是在正常技术更新期间添加的，因为企业购买的新设备已准备好IPv6。
Specialty legacy applications and wireless/satellite networks may be especially slow to transition to IPv6 capability due to upgrade costs, so plans must be made for backwards compatibility for these systems. Since some new IPv6 services cannot be provided through IPv4, and some legacy network connections may not yet be upgraded, tunneling mechanisms have to be provided on the backbone to provide IPv6 connectivity through to customer IPv6 applications still relying on legacy IPv4-only networks. The tunnels may provide host-based tunneling for individual customers or site-to-site tunnels to connect small IPv6 domains through IPv4-only networks. If any new applications are IPv6-only rather than dual-stacked, and need to interact with IPv4-only legacy applications, translators will be used as a transition mechanism of last resort during this stage.
由于升级成本的原因，专业遗留应用程序和无线/卫星网络向IPv6功能过渡的速度可能特别慢，因此必须为这些系统制定向后兼容性计划。由于一些新的IPv6服务无法通过IPv4提供，并且一些传统网络连接可能尚未升级，因此必须在主干上提供隧道机制，以便通过IPv6连接到仍然依赖传统IPv4网络的客户IPv6应用程序。这些隧道可以为单个客户提供基于主机的隧道，或者提供站点到站点的隧道，以便通过仅IPv4的网络连接小型IPv6域。如果任何新应用程序仅为IPv6而非双堆叠，并且需要与仅为IPv4的遗留应用程序进行交互，则在这一阶段，转换器将用作最后的过渡机制。
Stage 3: IPv6 Dominance
第三阶段：IPv6主导地位
Applications are deployed specifically to use IPv6 as benefit; thus, network backbone and nodes use IPv6 and not IPv4, except where IPv4 is legacy.
专门部署应用程序以使用IPv6作为优势；因此，网络主干和节点使用IPv6而不是IPv4，除非IPv4是传统的。
Authors' Addresses
作者地址
Jim Bound HP 110 Spitbrook Road Nashua, NH 03062 USA Phone: 603.465.3130 EMail: jim.bound@hp.com
吉姆前往美国新罕布什尔州纳舒亚市斯皮布鲁克路110号，邮编03062电话：603.465.3130电子邮件：吉姆。bound@hp.com
Yanick Pouffary HP Competency Center 950, Route des Colles, BP027, 06901 Sophia Antipolis CEDEX FRANCE Phone: + 33492956285 EMail: Yanick.pouffary@hp.com
Yanick Pouffary惠普能力中心950，Route des Colles，BP027，06901 Sophia Antipolis CEDEX FRANCE电话：+33492956285电子邮件：Yanick。pouffary@hp.com
Tim Chown School of Electronics and Computer Science University of Southampton Southampton SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk
南安普敦大学提姆电子与计算机科学学院南安普顿SO171BJ英国电子邮件：tjc@ecs.soton.ac.uk
David Green Command Information 13655 Dulles Technology Drive Suite 500 Herndon, VA 20171 USA Phone: 703.561.5937 EMail: green@commandinformation.com
David Green命令信息13655杜勒斯技术驱动套件500 Herndon，弗吉尼亚州20171美国电话：703.561.5937电子邮件：green@commandinformation.com
Steve Klynsma The MITRE Corporation 7515 Colshire Drive McLean, VA 22102-5708 USA Phone: 703-883-6469 EMail: sklynsma@mitre.org
Steve Klynsma The MITRE Corporation美国弗吉尼亚州科希尔大道7515号麦克林22102-5708电话：703-883-6469电子邮件：sklynsma@mitre.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。