Network Working Group J. Curran
Request for Comments: 5211 July 2008
Category: Informational
Network Working Group J. Curran
Request for Comments: 5211 July 2008
Category: Informational
An Internet Transition Plan
互联网转型计划
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认任何关于本RFC适用于任何目的的知识，并指出，除了IESG审查与IETF工作的冲突外，发布决定并非基于IETF审查。RFC编辑已选择自行发布本文件。有关更多信息，请参阅RFC 3932。
Abstract
摘要
This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model.
本备忘录提供了一个可能的计划，将互联网从主要基于IPv4的连接模式过渡到主要基于IPv6的连接模式。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. A Phased Transition Model .......................................2
2.1. Preparation Phase - Present to December 2009 ...............3
2.2. Transition Phase - January 2010 to December 2011 ...........4
2.3. Post-Transition Phase - January 2012 to the Future .........4
3. Summary .........................................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................5
6. Acknowledgments .................................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
1. Introduction ....................................................2
1.1. Requirements Language ......................................2
2. A Phased Transition Model .......................................2
2.1. Preparation Phase - Present to December 2009 ...............3
2.2. Transition Phase - January 2010 to December 2011 ...........4
2.3. Post-Transition Phase - January 2012 to the Future .........4
3. Summary .........................................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................5
6. Acknowledgments .................................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model.
本备忘录提供了一个可能的计划，将互联网从主要基于IPv4的连接模式过渡到主要基于IPv6的连接模式。
Other transition plans are possible and this purely informational document does not create an obligation on any party to undertake any of the actions specified herein, and the use of requirements language per RFC 2119 is only for the purpose of clearly describing the proposed transition plan in unambiguous terms.
其他过渡计划是可能的，本纯信息性文件不要求任何一方承担本文件规定的任何行动，根据RFC 2119使用需求语言仅用于明确描述拟议过渡计划。
The motivation for an Internet-wide transition plan is to facilitate coordination of expectations among innumerable, highly decentralized entities during a period of significant change, thus reducing risk to the defining Internet property of universal connectivity.
全互联网过渡计划的动机是在重大变革期间促进无数高度分散的实体之间的期望协调，从而降低互联网普遍连通性的定义风险。
The purpose of specifying this particular transition plan is to allow for overall assessment of the challenges of accomplishing the desired transition and to continue the discussion of Internet-wide transition plans in general.
指定此特定过渡计划的目的是为了全面评估实现预期过渡的挑战，并继续讨论整个互联网的过渡计划。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. RFC 2119 defines the use of these key words to help make the intent of Standards Track documents as clear as possible. While not a Standards Track document, the same key words are used in this document only for sake of clarity in describing the proposed transition plan.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。RFC 2119定义了这些关键词的使用，以帮助尽可能明确标准跟踪文档的意图。虽然不是标准跟踪文件，但本文件中使用相同的关键词只是为了清楚地描述拟议的过渡计划。
It is not reasonable to specify the changes that each and every system connected to the Internet must undergo in order to achieve the desired transition, as the number of connected systems precludes creating one plan that contains such a level of detail. Further, while there are common scenarios that may be specified for transitioning individual networks (refer to [RFC3750] and [RFC4057] for examples), the specific timeline and mechanisms utilized for a given network will be unique. Despite these challenges, it is necessary to coordinate expectations on an overall basis so that Internet-wide connectivity is maintained throughout the transition.
为了实现所需的过渡，指定每个连接到互联网的系统必须进行的更改是不合理的，因为连接系统的数量排除了创建一个包含此类详细程度的计划。此外，虽然存在可指定用于转换单个网络的常见场景（例如，参考[RFC3750]和[RFC4057]），但用于给定网络的特定时间线和机制将是唯一的。尽管存在这些挑战，但有必要在整体基础上协调预期，以便在整个过渡期间保持互联网范围的连通性。
This document specifies a three-phase transition plan that includes preparation, transition, and post-transition phases, and delineates the necessary activities within each phase based on the role that an organization plays in the provision and use of Internet services.
本文件规定了三个阶段的过渡计划，包括准备、过渡和过渡后阶段，并根据组织在提供和使用互联网服务方面的作用，描述了每个阶段内的必要活动。
An important distinction made in this transition plan is identifying the explicit requirement for existing end-site organizations to add IPv6-based connectivity to their public-facing servers during a transition phase. An accelerated adoption of IPv6 for public-facing servers enables new organizations in the post-transition phase to be connected to the Internet only via IPv6 and still have access to a substantial representative base of publicly available servers.
本过渡计划中的一个重要区别是明确要求现有终端站点组织在过渡阶段向其面向公众的服务器添加基于IPv6的连接。面向公众的服务器加快采用IPv6，使处于过渡后阶段的新组织能够仅通过IPv6连接到Internet，并且仍然能够访问大量具有代表性的公共可用服务器。
For nearly every organization, the task of IPv6-enabling their public-facing servers is far easier than undertaking an organization-wide adoption of IPv6. Still, the requirement for existing Internet-connected organizations to add IPv6 connectivity (even to a small number of systems) will be a significant hurdle and require a level of effort that may not be achievable given the lack of compelling additional benefits to these organizations [RFC1669]. This transition plan presumes that "connectivity is its own reward" [RFC1958] and that there still exists a sufficient level of cooperation among Internet participants to make this evolution possible.
对于几乎每个组织来说，支持其面向公众的服务器的IPv6任务要比在组织范围内采用IPv6容易得多。尽管如此，要求现有互联网连接组织添加IPv6连接（即使是少量系统）将是一个重大障碍，并且需要一定程度的努力，鉴于这些组织缺乏令人信服的额外好处，这可能无法实现[RFC1669]。该过渡计划假定“连通性是其自身的回报”[RFC1958]，互联网参与者之间仍然存在足够的合作水平，使这一演变成为可能。
The three proposed phases are: Preparation Phase, Transition Phase, and Post-Transition Phase. The timeline for the phases has been set to allow entry to the Post-Transition Phase prior to the projected IPv4 address pool exhaustion date [IPUSAGE].
建议的三个阶段是：准备阶段、过渡阶段和过渡后阶段。阶段的时间表已设置为允许在预计的IPv4地址池耗尽日期[IPUSAGE]之前进入过渡后阶段。
In the Preparation Phase, Service Providers pilot test their IPv6 network services, and end-site organizations prepare to provide Internet-facing services via IPv6-based connectivity while continuing to provide Internet-facing services via IPv4 connectivity.
在准备阶段，服务提供商对其IPv6网络服务进行了试点测试，最终站点组织准备通过基于IPv6的连接提供面向Internet的服务，同时继续通过IPv4连接提供面向Internet的服务。
During the Preparation Phase, the following principles apply:
在准备阶段，以下原则适用：
PREP1: Service Providers SHOULD offer pilot IPv6-based Internet Service to their Internet customers. IPv6-based Internet Service MAY be provided via IPv6 transition mechanisms (such as those described in [RFC4213], for example) or via native IPv6 network service.
PREP1：服务提供商应向其互联网客户提供基于IPv6的试点互联网服务。基于IPv6的互联网服务可以通过IPv6转换机制（例如[RFC4213]中描述的机制）或通过本机IPv6网络服务提供。
PREP2: Organizations SHOULD arrange for IPv6-based Internet connectivity for any Internet-facing servers (e.g., web, email, and domain name servers). Internet-facing IPv6 servers in this phase SHOULD use separate service names per [RFC4472] to avoid impact to production IPv4-based services unless the organization supports production IPv6 connectivity.
PREP2：组织应为任何面向Internet的服务器（如web、电子邮件和域名服务器）安排基于IPv6的Internet连接。此阶段中面向Internet的IPv6服务器应根据[RFC4472]使用单独的服务名称，以避免对基于IPv4的生产服务造成影响，除非该组织支持生产IPv6连接。
PREP3: Organizations MAY provide IPv6-based Internet connectivity to internal user communities.
PREP3：组织可以向内部用户社区提供基于IPv6的Internet连接。
In the Transition Phase, Service Providers offer production IPv6 and IPv4 services to their Internet customers. End-site organizations provide Internet-facing services in a production manner via IPv6- based connectivity in addition to IPv4-based connectivity.
在过渡阶段，服务提供商向其Internet客户提供生产IPv6和IPv4服务。除了基于IPv4的连接之外，终端站点组织还通过基于IPv6的连接以生产方式提供面向Internet的服务。
During the Transition Phase, the following principles apply:
在过渡阶段，以下原则适用：
TRANS1: Service Providers MUST offer IPv6-based Internet Service to their Internet customers. IPv6-based Internet Service SHOULD be via native IPv6 network service but MAY be via IPv6 transition mechanisms if necessary.
TRANS1：服务提供商必须向其互联网客户提供基于IPv6的互联网服务。基于IPv6的Internet服务应通过本机IPv6网络服务提供，但如有必要，可通过IPv6转换机制提供。
TRANS2: Organizations MUST arrange for IPv6-based Internet connectivity for any Internet-facing servers (e.g., web, email, and domain name servers). Internet-facing IPv6 servers SHOULD be treated as production by the organization, and SHOULD be treated as production by other Internet organizations.
TRANS2：组织必须为任何面向Internet的服务器（例如web、电子邮件和域名服务器）安排基于IPv6的Internet连接。面向Internet的IPv6服务器应被组织视为生产，并应被其他Internet组织视为生产。
TRANS3: Organizations SHOULD provide IPv6-based Internet connectivity to their internal user communities, and provide IPv6 internal supporting servers (e.g., DNS, DHCP). IPv6-based Internet connectivity MAY be via native IPv6 network service or MAY be via IPv6 transition mechanisms.
TRANS3：组织应向其内部用户社区提供基于IPv6的Internet连接，并提供IPv6内部支持服务器（例如DNS、DHCP）。基于IPv6的Internet连接可以通过本机IPv6网络服务，也可以通过IPv6转换机制。
In the Post-Transition Phase, end-site organizations provide all Internet-facing services via IPv6-based connectivity, thus allowing for new Internet customers connected solely by IPv6.
在过渡后阶段，终端站点组织通过基于IPv6的连接提供所有面向Internet的服务，从而允许仅通过IPv6连接的新Internet客户。
During the Post-Transition Phase, the following principles apply:
在过渡后阶段，以下原则适用：
POST1: Service Providers MUST offer IPv6-based Internet Service to their Internet customers. IPv6-based Internet Service SHOULD be via native IPv6 network service.
帖子1：服务提供商必须向其互联网客户提供基于IPv6的互联网服务。基于IPv6的Internet服务应通过本机IPv6网络服务提供。
POST2: Organizations MUST arrange for IPv6-based Internet connectivity for any Internet-facing servers (e.g., web, email, and domain name servers). Internet-facing IPv6 servers MUST be treated as production by the organization, and SHOULD be treated as production by other Internet organizations.
帖子2：组织必须为任何面向Internet的服务器（例如web、电子邮件和域名服务器）安排基于IPv6的Internet连接。面向Internet的IPv6服务器必须被组织视为生产，并且应该被其他Internet组织视为生产。
POST3: Organizations SHOULD provide IPv6-based Internet connectivity to internal user communities, and provide IPv6 internal supporting infrastructure (e.g., routers, DNS, DHCP, etc). IPv6-based Internet connectivity SHOULD be via native IPv6 network service or MAY be via IPv6 transition mechanisms.
帖子3：组织应向内部用户社区提供基于IPv6的互联网连接，并提供IPv6内部支持基础设施（如路由器、DNS、DHCP等）。基于IPv6的Internet连接应通过本机IPv6网络服务，也可以通过IPv6转换机制。
POST4: Service Providers MAY continue to offer IPv4-based Internet connectivity to their Internet customers. Organizations MAY continue to use IPv4-based Internet connectivity.
帖子4：服务提供商可能会继续向其互联网客户提供基于IPv4的互联网连接。组织可能会继续使用基于IPv4的Internet连接。
In order to facilitate full Internet-wide connectivity during the transition from IPv4-based connectivity to IPv6-based connectivity, a transition plan which provides clear guidance to organizations regarding expectations is necessary. As the specific expectations change over time, and vary greatly by organization, a phased approach is specified in this document, with the timeline for each phase set with the intention of allowing enough time for the necessary planning and deployment steps which each organization much undertake. This Internet Transition Plan provides for transition to predominantly IPv6-connectivity by January 2012 which, with careful management, may meet the overall requirements of allowing the Internet to scale as specified in "The Recommendation for the IP Next Generation Protocol" [RFC1752].
为了在从基于IPv4的连接过渡到基于IPv6的连接的过程中促进全互联网范围的连接，有必要制定一个过渡计划，为组织提供有关期望的明确指导。由于具体的期望随着时间的推移而变化，且因组织而异，因此本文件规定了分阶段的方法，并设定了每个阶段的时间表，目的是为每个组织开展必要的规划和部署步骤留出足够的时间。该互联网过渡计划规定在2012年1月之前过渡到以IPv6连接为主，经过仔细管理，可满足“IP下一代协议建议”[RFC1752]中规定的允许互联网扩展的总体要求。
This memo describes the transition of the Internet from IPv4-based connectivity to predominantly IPv6-based connectivity. This change inherently has security implications due to the widespread deployment of a new version of the Internet Protocol but these are beyond the scope of this document and are covered in [RFC4942]. This document raises no new security issues itself.
本备忘录描述了互联网从基于IPv4的连接过渡到主要基于IPv6的连接。由于新版本互联网协议的广泛部署，这种变化本身就具有安全影响，但这些内容超出了本文件的范围，并在[RFC4942]中进行了介绍。本文件本身没有提出新的安全问题。
While no new name or identifier space is created by this document, the policies for management of Internet Protocol version 4 (IPv4) address space may not provide for IPv4 availability through the Transition Phase as intended by this plan. The IANA should work with
虽然本文档未创建新的名称或标识符空间，但管理Internet协议版本4（IPv4）地址空间的策略可能不会按照本计划的预期在过渡阶段提供IPv4可用性。IANA应该与
all parties to develop policies per [RFC2050] which allow continued general availability of IPv4 address resources sufficiently long for any transition plan that receives widespread community support.
各方应根据[RFC2050]制定政策，允许IPv4地址资源在足够长的时间内持续普遍可用，以满足任何获得广泛社区支持的过渡计划。
This document would not have been possible without the abundant suggestions made by members of the Internet community at large, but specific thanks go to Fred Baker, Jim Bound, Scott Bradner, Bob Braden, Randy Bush, David Divins, Geoff Huston, Chris Morrow, Jordi Palet, Ken Shores, James Woodyatt, and the members of the IETF V6 Operations Working Group for their review and insightful suggestions for improvement.
如果没有广大互联网社区成员提出的大量建议，本文件就不可能实现，但要特别感谢弗雷德·贝克、吉姆·邦德、斯科特·布拉德纳、鲍勃·布拉登、兰迪·布什、大卫·迪文斯、杰夫·休斯顿、克里斯·莫罗、乔迪·佩莱、肯·肖尔斯、詹姆斯·伍迪亚特、，以及IETF V6运行工作组的成员，感谢他们的审查和深入的改进建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006.
[RFC4472]Durand，A.，Ihren，J.，和P.Savola，“IPv6 DNS的操作注意事项和问题”，RFC 4472，2006年4月。
[RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995.
[RFC1752]Bradner，S.和A.Mankin，“IP下一代协议的建议”，RFC 1752，1995年1月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年6月。
[RFC1669] Curran, J., "Market Viability as a IPng Criteria", RFC 1669, August 1994.
[RFC1669]Curran，J.，“作为IPng标准的市场可行性”，RFC 1669，1994年8月。
[IPUSAGE] Huston, G., IPv4 Address Report, February 2008, <http://www.potaroo.net/tools/ipv4/index.html>.
[IPUSAGE]休斯顿，G.，IPv4地址报告，2008年2月<http://www.potaroo.net/tools/ipv4/index.html>.
[RFC4057] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4057]Bound，J.，Ed.，“IPv6企业网络场景”，RFC 4057，2005年6月。
[RFC3750] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April 2004.
[RFC3750]Huitema，C.，Austein，R.，Satapati，S.，和R.van der Pol，“非托管网络IPv6过渡场景”，RFC 37502004年4月。
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
[RFC2050]哈伯德，K.，科斯特斯，M.，康拉德，D.，卡伦伯格，D.，和J.波斯特尔，“互联网注册IP分配指南”，BCP 12，RFC 2050，1996年11月。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, September 2007.
[RFC4942]Davies，E.，Krishnan，S.，和P.Savola，“IPv6过渡/共存安全考虑”，RFC 49422007年9月。
Author's Address
作者地址
John Curran 99 Otis Street Cambridge, MA USA 20190
美国马萨诸塞州剑桥奥的斯街99号John Curran 20190
EMail: jcurran@istaff.org
EMail: jcurran@istaff.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和http://www.rfc-editor.org/copyright.html，除本协议另有规定外，提交人保留其所有权利。
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.