[要約] RFC 6540は、すべてのIP対応ノードにIPv6サポートが必要であることを要求するものです。その目的は、IPv6の普及を促進し、IPv4アドレス枯渇問題に対処することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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ネットワーキングの新しい革新的な用途を見つけることにインターネットが成功したため、数十億のホストがインターネットを介して接続されており、ユニークなアドレス指定が必要です。この需要は、一意のIPv4アドレスのIANAグローバルプール[IANA-Execrast]の疲労につながり、その後、各地域インターネットレジストリ（RIR）のフリープールの消耗が続きます。-排気]。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対応」または「インターネット対応」デバイスを販売しています。またはエンタープライズネットワーク。また、既存のソフトウェアを更新してソフトウェアの装飾可能なデバイスで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のサポートが事実上要件です。既存のIPv4プロトコル仕様標準をIPv6を含むように更新するのではなく、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の初期ドキュメントの多くは、一般的な用語「IP」をより具体的な「IPv4」と同義に使用しています。この潜在的な混乱の例は、[RFC1812]、特にセクション1、2、および4にあります。RFC1812はIPv4ルーターの仕様であるため、この標準でのIPの一般的な使用は「IP」という用語として混乱を引き起こす可能性があります。これで、IPv4 IPv6、IPv6のみ、またはIPv4のみを意味すると解釈できます。さらに、[RFC1122]は、IPv6が含まれていないため、「IP」またはインターネットプロトコルスイートの完全な定義ではなくなりました。たとえば、セクション3.1には、インターネットレイヤーのIPv6の同等の標準への参照が含まれていません。セクション3.2はIPv4のみのプロトコルウォークスルーです。廃棄されましたが、これは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.
o IPv6サポートは、新規または更新されたIP実装でのIPv4サポートと比較した場合、品質と機能において同等以上でなければなりません。
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-exastr] apnic、「apnicプレスリリース - アジア太平洋IPv4排気のキーターニングポイント」、2011年4月<http：// www.apnic.net/__data/assets/pdf_file/0018/33246/ key-turning-Point-in-asia-pacific-ipv4- exhorion_english.pdf>。
[IANA-EXHAUST] IANA, "IANA IPv4 Address Space Registry", <http://www.iana.org/assignments/ipv4-address-space>.
[iana-exastr] iana、「iana ipv4アドレススペースレジストリ」、<http://www.iana.org/assignments/ipv4-address-pace>。
[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]ドンリー、C.、ハワード、L。、クアルシン、V。、ベルク、J。、およびJ.ドシ、「ネットワークアプリケーションに対するキャリアグレード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、「Internet Protocol、Version 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、「Internet Protocol、Version 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 Customer Edge Routersの基本要件」、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] Ford、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 6434、2011年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
Chris Donley CableLabs 858 Coal Creek Circle Louisville, CO 80027 US
クリス・ドンリー・ケーブルラブ858コールクリークサークルルイビル、コロラド州80027米国
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
Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 US
Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon、VA 20171 US
Phone: +1-703-345-3513
EMail: lee.howard@twcable.com