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
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のサポートがもはやオプションとみなされることを助言していません。また、IPv4の+ IPv6の、IPv6のみ、またはIPv4を意味することができます用語「IP」の用語「IP」は、汎用なると実装によって誤解される可能性の方法で使用されている既存のIETF文書内の場所があると警告します文脈やアプリケーションに応じて、-only。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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ネットワーキングのための新しい革新的な使用法を見つけることで、インターネットの成功に、ホストの数十億は現在、インターネットを介して接続された、ユニークなアドレス指定を必要としています。この需要は[APNICのユニークIPv4アドレスのIANAグローバルプール[IANA-EXHAUST]の枯渇につながっている、とAPNICである最初のものは、各地域インターネットレジストリ（RIR）のための無料のプールの枯渇が続きます-排気]。移行テクノロジとIPv4の寿命を延長する他の手段が存在しないが、ほぼすべてのそれらのを許可するための手段としてIPバージョン6（IPv6）の配置と比較して、最適な長期的な解決策であることから、それらを防ぐトレードオフが付属していインターネット上での成長を続けました。このトピックに関するいくつかの議論については、[RFC6269]と[NAT444-影響]を参照してください。
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]はとりわけ、グローバルに一意の制約に対する解決策は、IPv4の32ビットアドレス空間を表現することを対処する、として1995年に提案された、連続的な洗練の下で（例えば、[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対応、自然なハードウェアの更新サイクルが大幅に平均的な家庭でのIPv6サポートを増加する地点を押し出すために続けているではありません「IP対応」または「インターネット対応」機器を販売していますまたは企業ネットワーク。彼らはまた、ハードウェアの更新サイクルが独力でアクティブなネットワークからのIPv4専用デバイスをパージすることを期待するのは現実的ではないため、問題であるソフトウェア更新可能なデバイス上でのIPv6サポートを、有効にするために、既存のソフトウェアを更新しないことを選択されています妥当な時間。これは特に、ネットワークオペレータは、多くの場合、消費者が使用することを選択したハードウェアを管理していない消費者のスペースで、重大な問題です。平均的な消費者は彼らのインターネット対応デバイスとサービスで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でインターネット上で共存することが予想されるが、支配的なインターネット・プロトコル・バージョンなどのIPv6への支配的なインターネット・プロトコル・バージョンとしてIPv4からの移行が発生する必要があります。デバイスの早く大部分が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のサポートは、事実上の要件です。なくIPv6を含むように既存のIPv4プロトコル仕様規格を更新し、IETFは、IPv6を覆うスタンドアロン文書の完全に別個のセットを定義しています。したがって、実装は区別は、用語「IP」は、総称的に使用されるいくつかのIETF文書でIPv4とIPv6との間で行われなければならないと警告しています。 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の初期の文書の多くは、より具体的な「のIPv4」と同義一般用語「IP」を使用します。 RFC 1812は、IPv4ルーターの仕様、用語として「IP」の混乱を引き起こす可能性があり、この規格ではIPの一般的な使用であるので、この潜在的な混乱のいくつかの例としては、特にセクション1、2に、[RFC1812]で見つかった、と4することができます今のIPv4 + IPv6の、IPv6のみ、またはIPv4のみを意味すると解釈することができます。それは、IPv6が含まれていないので、さらに、[RFC1122]は、それ自体ではもはや「IP」の完全な定義やインターネット・プロトコル・スイートではありません。たとえば、3.1節は、インターネット層のIPv6のための同等の規格への参照が含まれていない、3.2節では、IPv4のみのためのプロトコルウォークスルーであり、3.2.1.1項では、明示的にそのバージョン番号のIPデータグラムがあること4でないことが必要ですIPv6転送に有害であると思われる、廃棄されました。この種の問題の追加インスタンスは、ここで議論されていないことが存在します。既存のRFCは、彼らがIPv4を意味するかもしれない場所で「IP」と言うので、実装者は、彼らが与えられた標準は、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.
新規または更新されたIPの実装におけるIPv4サポートと比較すると、O 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.
マーラAzinger、ブライアン・カーペンター、ビクターKuarsingh、ヤリArkko、スコット・ブリム、マーガレットワッサーマン、ジョー・タッチ、フレッド・ベイカー、ベンソンSchliesser、エリック・ローゼン、デヴィッド・ハリントン、そしてウェスリーエディ：自分のレビューとコメントのために以下の方々に感謝します。
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プレスリリース - アジア太平洋地域のIPv4枯渇の主なターニングポイント"、2011年4月、<のhttp：// www.apnic.net/__data/assets/pdf_file/0018/33246/キーTurning-ポイント・イン・アジア・パシフィック・IPv4- Exhaustion_English.pdf>。
[IANA-EXHAUST] IANA, "IANA IPv4 Address Space Registry", <http://www.iana.org/assignments/ipv4-address-space>.
[IANA-EXHAUST] 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-影響] Donley、C.、ハワード、L.、Kuarsingh、V.、ベルク、J.、およびJ.道志、 "ネットワークアプリケーションのキャリアグレードNATの影響を評価する"、進歩、2011年11月での作業。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、エド。、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[RFC1883]デアリング、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]デアリング、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]シン、H.、Beebee、W.、Donley、C.、スターク、B.、およびO. Troan、エド。、 "IPv6のカスタマーエッジルータのための基本要件"、RFC 6204、2011年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.、エド。、Boucadair、M.、デュラン、A.、リーバイス、P.、およびP.ロバーツ、RFC 6269、2011年6月、 "IPアドレスの共有に関する問題"。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434] Jankiewicz、E.、Loughney、J.、およびT. Narten氏、 "IPv6のノード要件"、RFC 6434、2011年12月。
Authors' Addresses
著者のアドレス
Wesley George Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 US
ウェズリージョージ・タイムワーナーケーブル13820日の出バレードライブハーンドン、VA 20171米国
Phone: +1 703-561-2540 EMail: wesley.george@twcable.com
電話：+1 703-561-2540電子メール：wesley.george@twcable.com
Chris Donley CableLabs 858 Coal Creek Circle Louisville, CO 80027 US
クリスDonley CableLabsの858コールクリークサークルルイビル、CO 80027米国
Phone: +1-303-661-9100 EMail: C.Donley@cablelabs.com
電話：+ 1-303-661-9100 Eメール：C.Donley@cablelabs.com
Christopher Liljenstolpe Big Switch Networks 430 Cowper St. Palo Alto, CA 94301 US
クリストファーLiljenstolpeビッグスイッチネットワーク430カウパーセントパロアルト、CA 94301米国
EMail: cdl@asgaard.org
メールアドレス：cdl@asgaard.org
Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 US
リー・ハワードタイムワーナーケーブル13820日の出バレードライブハーンドン、VA 20171米国
Phone: +1-703-345-3513 EMail: lee.howard@twcable.com
電話：+ 1-703-345-3513 Eメール：lee.howard@twcable.com