Internet Engineering Task Force (IETF) W. George
Request for Comments: 6540 Time Warner Cable
BCP: 177 C. Donley
Category: Best Current Practice CableLabs
ISSN: 2070-1721 C. Liljenstolpe
Big Switch Networks
L. Howard
Time Warner Cable
April 2012
Internet Engineering Task Force (IETF) W. George
Request for Comments: 6540 Time Warner Cable
BCP: 177 C. Donley
Category: Best Current Practice CableLabs
ISSN: 2070-1721 C. Liljenstolpe
Big Switch Networks
L. Howard
Time Warner Cable
April 2012
IPv6 Support Required for All IP-Capable Nodes
所有支持IP的节点都需要IPv6支持
Abstract
摘要
Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application.
鉴于全球缺乏可用的IPv4空间，以及IPv4扩展和转换技术的限制，本文档建议不再将IPv6支持视为可选。它还警告说，在现有IETF文档中，术语“IP”的使用方式可能会被实施者误解，因为术语“IP”成为一个通用术语，可能意味着IPv4+IPv6、仅IPv6或仅IPv4，具体取决于上下文和应用。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6540.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6540.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Clarifications and Recommendation ...............................3
3. Acknowledgements ................................................4
4. Security Considerations .........................................5
5. Informative References ..........................................5
1. Introduction ....................................................2
2. Clarifications and Recommendation ...............................3
3. Acknowledgements ................................................4
4. Security Considerations .........................................5
5. Informative References ..........................................5
IP version 4 (IPv4) has served to connect public and private hosts all over the world for over 30 years. However, due to the success of the Internet in finding new and innovative uses for IP networking, billions of hosts are now connected via the Internet and require unique addressing. This demand has led to the exhaustion of the IANA global pool of unique IPv4 addresses [IANA-EXHAUST], and will be followed by the exhaustion of the free pools for each Regional Internet Registry (RIR), the first of which is APNIC [APNIC-EXHAUST]. While transition technologies and other means to extend the lifespan of IPv4 do exist, nearly all of them come with trade-offs that prevent them from being optimal long-term solutions when compared with deployment of IP version 6 (IPv6) as a means to allow continued growth on the Internet. See [RFC6269] and [NAT444-IMPACTS] for some discussion on this topic.
IP版本4（IPv4）用于连接世界各地的公共和私有主机已有30多年的历史。然而，由于互联网在为IP网络寻找新的创新用途方面取得了成功，现在数十亿主机通过互联网连接，需要独特的寻址。这一需求导致了唯一IPv4地址的IANA全局池[IANA-DETANCE]耗尽，随后每个区域互联网注册中心（RIR）的免费池也将耗尽，其中第一个是APNIC[APNIC-DETANCE]。虽然过渡技术和其他延长IPv4寿命的手段确实存在，但几乎所有这些技术都存在权衡，与部署IP版本6（IPv6）作为允许互联网持续增长的手段相比，它们无法成为最佳的长期解决方案。有关此主题的一些讨论，请参见[RFC6269]和[NAT444-IMPACTS]。
IPv6 [RFC1883] was proposed in 1995 as, among other things, a solution to the limitations on globally unique addressing that IPv4's 32-bit addressing space represented, and has been under continuous refinement (e.g., [RFC2460]) and deployment ever since. The exhaustion of IPv4 and the continued growth of the Internet worldwide have created the driver for widespread IPv6 deployment.
IPv6[RFC1883]于1995年提出，作为解决IPv4的32位寻址空间所代表的全球唯一寻址限制的一种解决方案，并一直在不断完善（例如[RFC2460]）和部署。IPv4的耗尽和全球互联网的持续增长为IPv6的广泛部署创造了动力。
However, the IPv6 deployment necessary to reduce reliance on IPv4 has been hampered by a lack of ubiquitous hardware and software support throughout the industry. Many vendors, especially in the consumer space, have continued to view IPv6 support as optional. Even today, they are still selling "IP-capable" or "Internet-Capable" devices that are not IPv6-capable, which has continued to push out the point at which the natural hardware refresh cycle will significantly increase IPv6 support in the average home or enterprise network. They are also choosing not to update existing software to enable IPv6 support on software-updatable devices, which is a problem because it is not realistic to expect that the hardware refresh cycle will single-handedly purge IPv4-only devices from the active network in a reasonable amount of time. This is a significant problem, especially in the consumer space, where the network operator often has no control over the hardware the consumer chooses to use. For the same reason that the average consumer is not making a purchasing decision based on the presence of IPv6 support in their Internet-capable devices and services, consumers are unlikely to replace their still-functional Internet-capable devices simply to add IPv6 support -- they don't know or don't care about IPv6; they simply want their devices to work as advertised.
然而，由于整个行业普遍缺乏硬件和软件支持，减少对IPv4依赖所必需的IPv6部署受到了阻碍。许多供应商，特别是消费者领域的供应商，继续将IPv6支持视为可选。即使在今天，他们仍在销售不支持IPv6的“支持IP”或“支持Internet”设备，这将继续推动自然硬件刷新周期显著增加普通家庭或企业网络中的IPv6支持。他们还选择不更新现有软件以在软件可更新设备上启用IPv6支持，这是一个问题，因为期望硬件刷新周期将在合理的时间内单独从活动网络中清除仅IPv4的设备是不现实的。这是一个重大问题，尤其是在消费者领域，网络运营商通常无法控制消费者选择使用的硬件。出于同样的原因，普通消费者不会基于其支持互联网的设备和服务中是否存在IPv6支持而做出购买决定，消费者也不太可能仅仅为了添加IPv6支持而更换其仍能正常工作的支持互联网的设备——他们不知道或不关心IPv6；他们只是希望自己的设备能像广告宣传的那样工作。
This lack of support is making the eventual IPv6 transition considerably more difficult, and drives the need for expensive and complicated transition technologies to extend the life of IPv4-only devices as well as to eventually interwork IPv4-only and IPv6-only hosts. While IPv4 is expected to coexist on the Internet with IPv6 for many years, a transition from IPv4 as the dominant Internet Protocol version towards IPv6 as the dominant Internet Protocol version will need to occur. The sooner the majority of devices support IPv6, the less protracted this transition period will be.
这种缺乏支持的情况使最终的IPv6过渡变得更加困难，并促使人们需要昂贵而复杂的过渡技术来延长仅IPv4设备的使用寿命，以及最终实现仅IPv4和仅IPv6主机的互通。虽然IPv4预计将与IPv6在互联网上共存多年，但需要从IPv4作为主要互联网协议版本过渡到IPv6作为主要互联网协议版本。大多数设备越早支持IPv6，过渡期就越短。
To ensure interoperability and proper function after IPv4 exhaustion, support for IPv6 is virtually a requirement. Rather than update the existing IPv4 protocol specification standards to include IPv6, the IETF has defined a completely separate set of standalone documents that cover IPv6. Therefore, implementers are cautioned that a distinction must be made between IPv4 and IPv6 in some IETF documents where the term "IP" is used generically. Current requirements for IPv6 support can be found in [RFC6204] and [RFC6434]. Each of these documents contains specific information, requirements, and references to other Draft and Proposed Standards governing many aspects of IPv6 implementation.
为了确保IPv4耗尽后的互操作性和正常功能，实际上需要支持IPv6。IETF没有更新现有的IPv4协议规范标准以包括IPv6，而是定义了一组完全独立的涵盖IPv6的文档。因此，需要提醒实施者，在一些IETF文档中，必须区分IPv4和IPv6，其中术语“IP”是通用的。有关IPv6支持的当前要求，请参见[RFC6204]和[RFC6434]。这些文档中的每一个都包含特定的信息、要求以及对其他草案和提议的标准的引用，这些草案和提议的标准涉及IPv6实施的许多方面。
Many of the IETF's early documents use the generic term "IP" synonymously with the more specific "IPv4". Some examples of this potential confusion can be found in [RFC1812], especially in Sections 1, 2, and 4. Since RFC 1812 is an IPv4 router specification, the generic use of IP in this standard may cause confusion as the term "IP" can now be interpreted to mean IPv4 + IPv6, IPv6-only, or IPv4-only. Additionally, [RFC1122] is no longer a complete definition of "IP" or the Internet Protocol suite by itself, because it does not include IPv6. For example, Section 3.1 does not contain references to the equivalent standards for IPv6 for the Internet layer, Section 3.2 is a protocol walk-through for IPv4 only, and Section 3.2.1.1 explicitly requires that an IP datagram whose version number is not 4 be discarded, which would be detrimental to IPv6 forwarding. Additional instances of this type of problem exist that are not discussed here. Since existing RFCs say "IP" in places where they may mean IPv4, implementers are cautioned to ensure that they know whether a given standard is inclusive or exclusive of IPv6. To ensure interoperability, implementers building IP nodes will need to support both IPv4 and IPv6. If the standard does not include an integral definition of both IPv4 and IPv6, implementers need to use the other informative references in this document as companion guidelines for proper IPv6 implementations.
IETF的许多早期文件使用通用术语“IP”与更具体的“IPv4”同义。在[RFC1812]中可以找到这种潜在混淆的一些例子，特别是在第1、2和4节中。由于RFC 1812是IPv4路由器规范，本标准中IP的一般使用可能会引起混淆，因为术语“IP”现在可以解释为IPv4+IPv6、仅IPv6或仅IPv4。此外，[RFC1122]本身不再是“IP”或Internet协议套件的完整定义，因为它不包括IPv6。例如，第3.1节不包含对互联网层IPv6等效标准的引用，第3.2节是仅针对IPv4的协议演练，第3.2.1.1节明确要求丢弃版本号不是4的IP数据报，这将对IPv6转发有害。存在此类问题的其他实例，此处未讨论。由于现有的RFC在可能意味着IPv4的地方说“IP”，所以实施者要注意确保他们知道给定的标准是包含IPv6还是排除IPv6。为了确保互操作性，构建IP节点的实施者需要同时支持IPv4和IPv6。如果该标准未包含IPv4和IPv6的完整定义，则实施者需要使用本文档中的其他参考资料作为适当IPv6实施的配套指南。
To ensure interoperability and flexibility, the best practices are as follows:
为确保互操作性和灵活性，最佳做法如下：
o New IP implementations must support IPv6.
o 新的IP实现必须支持IPv6。
o Updates to current IP implementations should support IPv6.
o 对当前IP实施的更新应支持IPv6。
o IPv6 support must be equivalent or better in quality and functionality when compared to IPv4 support in a new or updated IP implementation.
o 与新的或更新的IP实现中的IPv4支持相比，IPv6支持在质量和功能上必须相当或更好。
o New and updated IP networking implementations should support IPv4 and IPv6 coexistence (dual-stack), but must not require IPv4 for proper and complete function.
o 新的和更新的IP网络实现应支持IPv4和IPv6共存（双堆栈），但不要求IPv4才能正常和完整地运行。
o Implementers are encouraged to update existing hardware and software to enable IPv6 wherever technically feasible.
o 鼓励实施者更新现有硬件和软件，以便在技术上可行的情况下启用IPv6。
Thanks to the following people for their reviews and comments: Marla Azinger, Brian Carpenter, Victor Kuarsingh, Jari Arkko, Scott Brim, Margaret Wasserman, Joe Touch, Fred Baker, Benson Schliesser, Eric Rosen, David Harrington, and Wesley Eddy.
感谢以下人士的评论和评论：玛拉·阿辛格、布赖恩·卡彭特、维克多·夸辛格、贾里·阿尔科、斯科特·布里姆、玛格丽特·沃瑟曼、乔·图奇、弗雷德·贝克、本森·施利塞、埃里克·罗森、大卫·哈林顿和韦斯利·艾迪。
There are no direct security considerations generated by this document, but existing documented security considerations for implementing IPv6 will apply.
本文档没有生成直接的安全注意事项，但现有的用于实施IPv6的文档化安全注意事项将适用。
[APNIC-EXHAUST]
APNIC, "APNIC Press Release - Key Turning Point in Asia
Pacific IPv4 Exhaustion", April 2011, <http://
www.apnic.net/__data/assets/pdf_file/0018/33246/
Key-Turning-Point-in-Asia-Pacific-IPv4-
Exhaustion_English.pdf>.
[APNIC-EXHAUST]
APNIC, "APNIC Press Release - Key Turning Point in Asia
Pacific IPv4 Exhaustion", April 2011, <http://
www.apnic.net/__data/assets/pdf_file/0018/33246/
Key-Turning-Point-in-Asia-Pacific-IPv4-
Exhaustion_English.pdf>.
[IANA-EXHAUST] IANA, "IANA IPv4 Address Space Registry", <http://www.iana.org/assignments/ipv4-address-space>.
[IANA-TEASH]IANA，“IANA IPv4地址空间注册表”<http://www.iana.org/assignments/ipv4-address-space>.
[NAT444-IMPACTS] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J. Doshi, "Assessing the Impact of Carrier-Grade NAT on Network Applications", Work in Progress, November 2011.
[NAT444-IMPACTS]Donley，C.，Howard，L.，Kuarsingh，V.，Berg，J.，和J.Doshi，“评估运营商级NAT对网络应用的影响”，正在进行的工作，2011年11月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，Ed.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[RFC1883]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 1883，1995年12月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, Ed., "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011.
[RFC6204]Singh，H.，Beebee，W.，Donley，C.，Stark，B.，和O.Troan，Ed.，“IPv6客户边缘路由器的基本要求”，RFC 62042011年4月。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，Ed.，Boucadair，M.，Durand，A.，Levis，P.，和P.Roberts，“IP地址共享问题”，RFC 6269，2011年6月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434]Jankiewicz，E.，Loughney，J.和T.Narten，“IPv6节点要求”，RFC 64342011年12月。
Authors' Addresses
作者地址
Wesley George Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 US
韦斯利·乔治·时代华纳有线电视13820美国弗吉尼亚州赫恩登日出谷大道20171
Phone: +1 703-561-2540
EMail: wesley.george@twcable.com
Phone: +1 703-561-2540
EMail: wesley.george@twcable.com
Chris Donley CableLabs 858 Coal Creek Circle Louisville, CO 80027 US
Chris Donley CableLabs 858美国科罗拉多州路易斯维尔市煤溪圈80027
Phone: +1-303-661-9100
EMail: C.Donley@cablelabs.com
Phone: +1-303-661-9100
EMail: C.Donley@cablelabs.com
Christopher Liljenstolpe Big Switch Networks 430 Cowper St. Palo Alto, CA 94301 US
克里斯托弗·利尔延斯托尔佩大交换机网络美国加利福尼亚州帕洛阿尔托市考珀大街430号，邮编94301
EMail: cdl@asgaard.org
EMail: cdl@asgaard.org
Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 US
美国弗吉尼亚州赫恩登日出谷大道13820号李霍华德时代华纳有线电视公司，邮编20171
Phone: +1-703-345-3513
EMail: lee.howard@twcable.com
Phone: +1-703-345-3513
EMail: lee.howard@twcable.com