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はインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、このRFCのフィットネスの知識を否認し、公開する決定がIETF仕事との競合のためのIESGレビューとは別にIETFレビューに基づいていないことを指摘しています。 RFC Editorはその裁量でこの文書を公開することを選択しました。詳細については、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.
このメモは、主にIPv6ベースの接続モデルに主としてIPv4ベースの接続モデルからインターネットに移行するための一つの可能な計画を提供します。
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
This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model.
このメモは、主にIPv6ベースの接続モデルに主としてIPv4ベースの接続モデルからインターネットに移行するための一つの可能な計画を提供します。
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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のみを介してインターネットに接続されており、まだ公に利用可能なサーバの実質的な代表ベースへのアクセス権を持つことができます。
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].
3提案された相は、次のとおり準備フェーズ遷移相、移行後フェーズ。相のタイムラインは[IPUSAGE】従来投影のIPv4アドレスプールの枯渇日に遷移後フェーズへのエントリを許可するように設定されています。
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ネットワークサービスをテストし、エンドサイト組織は、IPv4接続を経由してインターネットに接続されたサービスを提供し続けながら、IPv6ベースの接続を経由してインターネットに接続されたサービスを提供する準備をします。
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ベースのインターネットサービス（例えば、[RFC4213]に記載のものなど）のIPv6移行メカニズムを介して、またはネイティブの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：組織は、任意のインターネットに接続しているサーバのIPv6ベースのインターネット接続（例えば、ウェブ、電子メール、およびドメインネームサーバ）を手配すべきです。インターネットに面したこの段階でのIPv6のサーバーは、組織が生産IPv6接続をサポートしていない限り、生産IPv4ベースのサービスへの影響を避けるために、[RFC4472]ごとに別々のサービス名を使用すべきです。
PREP3: Organizations MAY provide IPv6-based Internet connectivity to internal user communities.
PREP3：組織は、内部ユーザコミュニティにIPv6ベースのインターネット接続を提供することができます。
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.
移行フェーズでは、サービスプロバイダは、彼らのインターネットの顧客に生産IPv6とIPv4サービスを提供しています。エンドサイト団体は、IPv4ベースの接続に加えてIPv6-ベースの接続を経由して、生産的にインターネットに接続されたサービスを提供しています。
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ベースのインターネットサービスは、ネイティブ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：組織は、任意のインターネットに接続しているサーバのIPv6ベースのインターネット接続（例えば、ウェブ、電子メール、およびドメインネームサーバ）を手配しなければなりません。インターネットに面したIPv6サーバーは、組織によって生産として扱われるべきであり、他のインターネット関連団体による生産として扱われるべきです。
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ベースのインターネット接続を提供し、サーバ（例えば、DNS、DHCP）をサポートするIPv6の内部を提供する必要があります。 IPv6ベースのインターネット接続は、ネイティブ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の接続のみによって新しいインターネットの顧客を可能に、IPv6ベースの接続を経由して、すべてのインターネットに接続されたサービスを提供しています。
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.
POST1：サービスプロバイダは、彼らのインターネットの顧客にIPv6ベースのインターネットサービスを提供しなければなりません。 IPv6ベースのインターネットサービスは、ネイティブ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.
POST2：組織は、任意のインターネットに接続しているサーバのIPv6ベースのインターネット接続（例えば、ウェブ、電子メール、およびドメインネームサーバ）を手配しなければなりません。インターネットに面したIPv6サーバーは、組織によって生産として扱わなければならない、と他のインターネット関連団体による生産として扱われるべきです。
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.
POST3：組織は、内部ユーザコミュニティにIPv6ベースのインターネット接続を提供し、IPv6の内部インフラストラクチャ（例えば、ルータ、DNS、DHCP、等）をサポートすべきです。 IPv6ベースのインターネット接続は、ネイティブ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.
POST4：サービスプロバイダは、彼らのインターネットの顧客にIPv4ベースのインターネット接続を提供し続けることができます。組織は、IPv4ベースのインターネット接続を使用し続けることができます。
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].
IPv6ベースの接続にIPv4ベースの接続からの移行時に完全なインターネット全体の接続を容易にするために、期待に関する組織への明確な指針を提供する移行計画が必要です。特定の期待が時間とともに変化し、組織によって大きく異なるため、段階的なアプローチは、各組織がずっと引き受ける必要な計画および展開ステップのための十分な時間を許可することを意図して設定し、各フェーズのタイムラインで、この文書で指定されています。このインターネット移行計画は、慎重な管理と、インターネットは[RFC1752]「IP次世代プロトコルのための勧告」のように指定された拡張させることの全体的な要件を満たすことができる、2012年1月によって主にIPv6に接続への移行を提供します。
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 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.
新しい名前または識別子空間は、このドキュメントで作成されませんが、インターネットプロトコルバージョン4（IPv4）アドレス空間の管理のための政策は、この計画によって、意図したとおりの移行フェーズを通じてIPv4の可用性を提供しない場合があります。 IANAは、広範なコミュニティのサポートを受けて任意の移行計画のために十分に長いIPv4アドレス資源の継続的な一般的な可用性を許可[RFC2050]あたりの政策を策定するために、すべての関係者と協力すべきです。
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.
、この文書は、広くインターネットコミュニティのメンバーによって作られた豊富な提案なしで可能でなかったでしょうが、特定のおかげでジム・バウンドフレッド・ベイカー、スコット・ブラッドナー、ボブブレーデン、ランディブッシュ、デビッドDivins、ジェフ・ヒューストン、クリス・モローに行きますジョルディPalet、ケン・ショアーズ、ジェームズWoodyatt、及びその見直しと改善のための洞察力の提案のためのIETF V6事業ワーキンググループのメンバー。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.ギリガン、 "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]デュラン、A.、Ihren、J.、およびP. Savola、RFC 4472 "IPv6のDNSで運用考慮事項と課題"、2006年4月。
[RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995.
[RFC1752]ブラドナー、S.およびA.マンキン、 "IP次世代プロトコルのための勧告"、RFC 1752、1995年1月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、エド。、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC1669] Curran, J., "Market Viability as a IPng Criteria", RFC 1669, August 1994.
"IPngの基準として市場生存率" [RFC1669]カラン、J.、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]バウンド、J.、エド。、 "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.のファンデルポール、 "非管理ネットワークのIPv6移行シナリオ"、RFC 3750、2004年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.、Kosters、M.、コンラッド、D.、Karrenberg、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]デイヴィス、E.、クリシュナン、S.、およびP. Savola、 "IPv6移行/共存のセキュリティの考慮事項"、RFC 4942、2007年9月。
Author's Address
著者のアドレス
John Curran 99 Otis Street Cambridge, MA USA 20190
ジョン・カラン99オーティス・ストリート、ケンブリッジ、MA USA 20190
EMail: jcurran@istaff.org
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。