Network Working Group G. Tsirtsis
Request for Comments: 4977 Qualcomm
Category: Informational H. Soliman
Elevate Technologies
August 2007
Problem Statement: Dual Stack Mobility
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems. Deployment and operational issues motivate the use of a single mobility management protocol. This document discusses such motivations. The document also discusses requirements for the Mobile IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node.
この文書では、デュアルスタックモバイルノードのためのモビリティ管理に関連する問題について説明します。現在、2つのモビリティ管理プロトコルは、IPv4とIPv6のために定義されています。両方のデュアルスタックモバイルノードにデプロイすると、多くの問題を紹介します。導入と運用上の問題は、単一のモビリティ管理プロトコルの使用を動機づける。この文書では、このような動機を説明します。彼らは、デュアルスタックノードのためのモビリティ管理をサポートできるように、文書はまた、モバイルIPv4（MIPv4の）およびモバイルIPv6（MIPv6の）プロトコルのための要件について説明します。
Table of Contents
目次
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction and Motivation . . . . . . . . . . . . . . . . . . 2
3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3
3.1. The Impossibility of Maintaining IP Connectivity . . . . . 4
3.2. Implementation Burdens . . . . . . . . . . . . . . . . . . 4
3.3. Operational Burdens . . . . . . . . . . . . . . . . . . . . 4
3.4. Mobility Management Inefficiencies . . . . . . . . . . . . 4
3.5. IPv4 to IPv6 Transition Mechanisms . . . . . . . . . . . . 5
4. Conclusions and Recommendations . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
This document uses the following terms as defined in Stateless IP/ ICMP Translation (SIIT) [RFC2765]: IPv4-capable node, IPv4-enabled node, IPv6-capable node, IPv6-enabled node.
IPv4対応のノードはIPv4対応のノード、IPv6対応のノード、IPv6対応のノード：ステートレスIP / ICMP翻訳（SIIT）[RFC2765]で定義されるように、このドキュメントは次の用語を使用します。
The following terms are introduced in this document:
以下の用語は、この文書で紹介されています。
- MIPv4-capable node:
- のMIPv4対応ノード。
A node that supports MIPv4 [RFC3344] in its implementation. This allows the mobile node to configure a home address (statically or dynamically) and use such address in its Mobile IPv4 signaling. A MIPv4-capable node may also be IPv6-capable or IPv6-enabled and must be IPv4-capable.
その実装でのMIPv4 [RFC3344]をサポートノード。これは、ホームアドレス（静的または動的）を設定し、そのモバイルIPv4シグナリングにそのようなアドレスを使用するモバイルノードを可能にします。 MIPv4対応のノードは、IPv6対応であるか、IPv6対応とIPv4対応しなければならないことができます。
- MIPv6-capable node:
- MIPv6の対応ノード。
A node that supports MIPv6 [RFC3775] by configuring a home address and using such address in its Mobile IPv6 signaling. A MIPv6- enabled node may also be IPv4-capable or IPv4-enabled and must be IPv6-capable.
ホームアドレスを構成し、そのモバイルIPv6シグナリングにそのようなアドレスを使用して、MIPv6の[RFC3775]をサポートノード。 MIPv6-イネーブルノードはIPv4対応またはIPv4が有効であってもよく、IPv6対応でなければなりません。
A MIPv4-capable node can use Mobile IPv4 [RFC3344] to maintain connectivity while moving between IPv4 subnets. Similarly, a MIPv6- capable node can use Mobile IPv6 [RFC3775] to maintain connectivity while moving between IPv6 subnets.
MIPv4対応のノードは、IPv4サブネット間を移動しながら接続を維持するために、モバイルIPv4 [RFC3344]を使用することができます。同様に、MIPv6-可能なノードは、IPv6サブネット間を移動しながら接続を維持するために、モバイルIPv6 [RFC3775]を使用することができます。
One of the ways of migrating to IPv6 is to deploy nodes that are both IPv4 and IPv6 capable. Such nodes will be able to get both IPv4 and IPv6 addresses and thus can communicate with the current IPv4 Internet as well as any IPv6 nodes and networks as they become available.
IPv6への移行の方法のいずれかは、IPv4とIPv6の両方が可能なノードを展開することです。このようなノードは、IPv4およびIPv6アドレスの両方を得ることができるようになり、従って、それらが利用可能になると、現在のIPv4インターネットならびに任意のIPv6ノードとネットワークと通信することができます。
A node that is both IPv4 and IPv6 capable can use Mobile IPv4 for its IPv4 stack and Mobile IPv6 for its IPv6 stack so that it can move between IPv4 and IPv6 subnets. While this is possible, it does not ensure connectivity since that also depends on the IP version support of the network accessed. Supporting Mobile IPv4 and Mobile IPv6 is also more inefficient since it requires:
それはIPv4とIPv6サブネット間を移動できるように、可能なIPv4とIPv6の両方のノードは、IPv6スタックのためのIPv4スタックのためのモバイルIPv4及びモバイルIPv6を使用することができます。これは可能ではあるがそれはまた、アクセスネットワークのIPバージョンのサポートに依存しているため、それは接続性を保証するものではありません。それが必要とするため、モバイルIPv4およびモバイルIPv6をサポートすることも、より非効率的です。
- Mobile nodes to be both MIPv4 and MIPv6 capable.
- モバイルノードができるのMIPv4とMIPv6の両方ことができます。
- Mobile nodes to send two sets of signaling messages on every handoff.
- モバイルノードは、すべてのハンドオフにシグナリングメッセージの二組を送信します。
- Network Administrators to run and maintain two sets of mobility management systems on the same network, with each of these systems requiring its own set of optimizations.
- ネットワーク管理者は、これらの各システムは、最適化の独自のセットを必要とし、同じネットワーク上のモビリティ管理システムの2セットを実行し、維持します。
This document discusses the potential inefficiencies, IP connectivity problems, and operational issues that are evident when running both mobility management protocols simultaneously. It also proposes a work area to be taken up by the IETF on the subject and discusses requirements for appropriate solutions.
この文書では、同時に両方のモビリティ管理プロトコルを実行するときに明らかである潜在的な非効率性、IP接続の問題、および運用上の問題について説明します。また、被写体にIETFによって取り込まれるために作業領域を提案し、適切なソリューションのための要件について説明します。
Mobile IP (v4 and v6) uses a signaling protocol (Registration requests in MIPv4 [RFC3344] and Binding updates in MIPv6 [RFC3775]) to set up tunnels between two end points. At the moment, Mobile IP signaling is tightly coupled to the address family (i.e., IPv4 or IPv6) used, in the connections it attempts to manipulate. There are no fundamental technical reasons for such coupling. If Mobile IP were viewed as a tunnel-setup protocol, it should be able to set up IP in IP tunnels, independently of the IP version used in the outer and inner headers. Other protocols -- for example, SIP [RFC3261] -- are able to use either an IPv4- or IPv6-based signaling plane to manipulate IPv4 and IPv6 connections.
モバイルIP（V4およびV6）は、二つのエンドポイント間のトンネルをセットアップするためにシグナリングプロトコル（MIPv4の中の登録要求[RFC3344]およびMIPv6のバインディングで更新[RFC3775]）を使用します。現時点では、モバイルIPシグナリングはしっかりそれが操作しようとする接続において、使用されるアドレスファミリー（すなわち、IPv4またはIPv6）に結合されています。このようなカップリングのための基本的な技術的な理由はありません。モバイルIPトンネルセットアッププロトコルとして見た場合には、外側と内側のヘッダーで使用されるIPバージョンとは無関係に、IPトンネル内のIPを設定することができなければなりません。他のプロトコル - 例えば、SIP [RFC3261]は - IPv4およびIPv6接続を操作するIPv4-またはIPv6ベースのシグナリングプレーンのいずれかを使用することができます。
A node that is both MIPv4 and MIPv6 capable, will require the following to roam within the Internet:
可能なのMIPv4とMIPv6の両方のノード、インターネット内でローミングするために、次を必要とするであろう。
- The network operator needs to ensure that the home agent supports both protocols or that it has two separate Home Agents supporting the two protocols, each requiring its own management.
- ネットワークオペレータは、ホームエージェントは、両方のプロトコルをサポートしていることを確認する必要があるか、それは、それぞれが独自の管理を必要とする、2つのプロトコルをサポートする2つの別々のホームエージェントを持っていること。
- Double the amount of configuration in the mobile node and the home agent (e.g., security associations).
- モバイルノード内の構成の二量及びホーム・エージェント（例えば、セキュリティアソシエーション）。
- IP-layer local network optimizations for handovers will also need to be duplicated.
- ハンドオーバのためにIPレイヤローカルネットワークの最適化も重複する必要があります。
We argue that all of the above will make the deployment of Mobile IPv6, as well as any dual stack solution in a mobile environment, harder. We will discuss some of the issues with the current approach separately in the following sections.
私たちは、上記のすべては、モバイルIPv6の展開だけでなく、モバイル環境における任意のデュアルスタック・ソリューション、困難を行いますと主張しています。私たちは、次のセクションで個別に現在のアプローチで問題のいくつかを説明します。
Even if a mobile node is both MIPv4 and MIPv6 capable, connectivity across different networks would not, in fact, be guaranteed since that also depends on the IPv4/IPv6 capabilities of the networks the mobile is visiting; i.e., a node attempting to connect via a IPv4- only network would not be able to maintain connectivity of its IPv6 applications and vice versa. This is potentially the most serious problem discussed in this document.
モバイルノードは、のMIPv4とMIPv6の両方が可能であっても、それはまた、移動体が訪問しているネットワークのIPv4 / IPv6の機能に依存するため、異なるネットワーク間の接続は、実際には、保証されません。即ち、IPv4-のみネットワークを介して接続しようとするノードは、IPv6アプリケーションおよびその逆の接続を維持することができないだろう。これは、潜在的に、このドキュメントで説明する最も深刻な問題です。
As mentioned above, a node that is IPv4 and IPv6 capable must also be MIPv4 and MIPv6 capable to roam within the Internet. The ability to employ both IP versions from one mobility protocol makes it possible to implement just that one protocol, assuming the protocol choice is known. However, in situations where the mobile node must be capable of working in any network, it may still need two protocols.
上述したように、可能なIPv4およびIPv6であるノードは、MIPv4のとインターネット内でローミングすることが可能なMIPv6のなければなりません。 1つのモビリティプロトコルの両方からIPバージョンを用いる能力は、プロトコルの選択が知られていると仮定すると、ただ1つのプロトコルを実装することが可能となります。しかし、モバイルノードは、任意のネットワークで作業することが可能でなければならない状況では、それはまだ2つのプロトコルが必要な場合があります。
As mentioned earlier, deploying both protocols will require managing both protocols in the mobile node and the home agent. This adds significant operational issues for the network operator. It would certainly require the network operator to have deep knowledge in both protocols, which is something an operator may not be able to justify due to the lack of substantial gains.
先に述べたように、両方のプロトコルを展開することは、モバイルノードとホームエージェントの両方のプロトコルを管理する必要があります。これは、ネットワークオペレータのための重要な運用上の問題が追加されます。それは確かに、オペレータがかなりの利益が不足しているため正当化することができないかもしれない何かで両方のプロトコルの深い知識を、持っているネットワークオペレータを必要とします。
In addition, deploying both protocols will require duplication of security credentials on mobile nodes and home agents. This includes IPsec security associations, keying material, and new authentication protocols for Mobile IPv6, in addition to the security credentials and associations required by Mobile IPv4. Depending on the security mechanisms used and with some further work, it might be possible to rely on one set of common credentials. Assuming nothing else changes, however, such duplication is again significant with no gain to the operator or the mobile node.
また、両方のプロトコルを展開することは、モバイルノードとホームエージェントのセキュリティ資格情報の重複を必要とします。これは、モバイルIPv4で必要とされるセキュリティ証明書と団体に加えて、IPsecセキュリティ協会、キーイング材料、およびモバイルIPv6のための新しい認証プロトコルを含んでいます。使用されているセキュリティ・メカニズムにといくつかの更なる作業とによって、一般的な資格情報の1セットに依存することは可能かもしれません。他には何も変更を想定すると、しかし、そのような重複は再びオペレータにノーゲインまたはモバイルノードと重要です。
Suppose that a mobile node is moving within a dual stack access network. Every time the mobile node moves, it needs to send two mobile IP messages to its home agent to allow its IPv4 and IPv6 connections to survive. There is no reason for such duplication. If local mobility optimizations were deployed (e.g., Hierarchical Mobile IPv6 (HMIPv6) [RFC4140], Fast handovers for Mobile IPv4 [RFC4068]), the mobile node will need to update the local agents running each protocol. Ironically, one local agent might be running both HMIPv6 and local MIPv4 home agent. Clearly, it is not desirable to have to send two messages and complete two sets of transactions for the same fundamental optimization.
モバイルノードはデュアルスタックアクセスネットワーク内で移動していることとします。たびに、移動ノードの移動は、それがそのIPv4とIPv6の接続は生き残ることができるようにそのホームエージェントに2つのモバイルIPメッセージを送信する必要があります。こうした重複のための理由はありません。ローカル・モビリティ・最適化が展開された場合（例えば、階層化モバイルIPv6（HMIPv6の）[RFC4140]、モバイルIPv4の高速ハンドオーバ[RFC4068]）、モバイルノードは、各プロトコルを実行しているローカルエージェントを更新する必要があります。皮肉なことに、一つのローカルエージェントは、HMIPv6の、地元のMIPv4ホームエージェントの両方を実行している可能性があります。明らかに、同じ基本的な最適化のためのトランザクションの二組を2つのメッセージを送信し、完了する必要がすることは望ましくありません。
Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will complicate mobility management within the Internet and increase the amount of bandwidth needed at the critical handover time for no apparent gain.
従って、モバイルIPv4とモバイルIPv6のような並列動作は、インターネット内のモビリティ管理を複雑にし、明白な利益のための重要なハンドオーバ時に必要な帯域幅の量を増加させるであろう。
The IETF has standardized a number of transition mechanisms to allow networks and end nodes to gain IPv6 connectivity while the Internet is migrating from IPv4 to IPv6. However, while some transition mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none of the known mechanisms have been shown to assist with the issues described in this document.
IETFはインターネットは、IPv4からIPv6へ移行している間ネットワークとエンドノードは、IPv6接続性を獲得することを可能にする移行メカニズムの数を標準化しました。いくつかの移行メカニズムがモバイルIPv4又はモバイルIPv6と組み合わせることができるがしかし、公知の機構のいずれも、本文書で説明している問題を支援するために示されていません。
The points above highlight the tight coupling in both Mobile IPv4 and Mobile IPv6 between signaling and the IP addresses used by upper layers. Given that Mobile IPv4 is currently deployed and Mobile IPv6 is expected to be deployed, there is a need for gradual transition from IPv4 mobility management to IPv6. Running both protocols simultaneously is inefficient and has the problems described above. The gradual transition can be done when needed or deemed appropriate by operators or implementers. In the meantime, it is important to ensure that the problems listed above can be avoided. Hence, this section lists some actions that should be taken by the IETF to address the problems listed above, without mandating the use of two mobility management protocols simultaneously.
ハイライト上記ポイントシグナリングと上位層によって使用されるIPアドレスとの間のモバイルIPv4とモバイルIPv6の両方に緊密な結合。モバイルIPv4が現在展開されており、モバイルIPv6が展開されると予想されていることを考えると、IPv6へのIPv4モビリティ管理から徐々に移行の必要性があります。同時に両方のプロトコルを実行すると、非効率的であると、上記の問題を抱えています。必要に応じて、またはオペレータまたは実装者が適当と認めるときに徐々に移行を行うことができます。一方で、上記の問題を回避できることを確認することが重要です。したがって、このセクションでは、同時に2つのモビリティ管理プロトコルの使用を義務付けるせずに、上記の問題に対処するためにIETFによって取るべきいくつかのアクションを示しています。
The Mobile IPv6 Working Group has reached the view that to allow for a gradual transition based on current standards and deployment, the following work areas would be reasonable:
モバイルIPv6ワーキンググループは、以下の作業領域が合理的である、現在の標準と展開に基づいて段階的な移行を可能にするためのビューに達しました。
- It should be possible to run one mobility management protocol that can manage mobility for both IPv4 and IPv6 addresses used by upper layers. Both Mobile IPv4 and Mobile IPv6 should be able to perform such tasks. It may not be possible to support route optimization for Mobile IPv6 in all cases; however, mobility management and session continuity can be supported.
- 上位層で使用されるIPv4アドレスとIPv6アドレスの両方のためのモビリティを管理することができます1つのモビリティ管理プロトコルを実行することが可能です。モバイルIPv4およびモバイルIPv6の両方が、そのようなタスクを実行することができるはずです。すべてのケースでは、モバイルIPv6の経路最適化をサポートすることはできないかもしれません。しかし、モビリティ管理およびセッションの継続をサポートすることができます。
- It should be possible to create IPv4 extensions to Mobile IPv6 so that an IPv4 and IPv6 capable mobile node can register its IPv4 and IPv6 home addresses to an IPv4- and IPv6-enabled Home Agent using MIPv6 signaling only.
- IPv4およびIPv6対応モバイルノードがMIPv6のが唯一のシグナリングを使用してIPv4-とIPv6対応ホームエージェントにそのIPv4とIPv6のホームアドレスを登録することができるように、モバイルIPv6へのIPv4拡張機能を作成することが可能です。
- It should be possible to create IPv6 extensions to Mobile IPv4 so that an IPv4 and IPv6 capable mobile node can register its IPv4 and IPv6 home addresses to an IPv4- and IPv6-enabled Home Agent using Mobile IPv4 signaling only.
- IPv4およびIPv6対応モバイルノードが唯一のシグナリングモバイルIPv4を使用してIPv4-とIPv6対応ホームエージェントにそのIPv4とIPv6のホームアドレスを登録することができるようにモバイルIPv4へのIPv6拡張機能を作成することが可能です。
- It should also be possible to extend MIPv4 [RFC3344] and MIPv6 [RFC3775] so that a mobile node can register a single care-of address (IPv4 or IPv6) to which IPv4 and/or IPv6 packets can be tunneled.
- また、移動ノードがIPv4および/またはIPv6パケットがトンネリング可能な単気付アドレス（IPv4またはIPv6）を登録できるようにMIPv4の[RFC3344]およびMIPv6の[RFC3775]を拡張することが可能であるべきです。
If the IETF chooses to pursue all these paths, a vendor could choose to support one mobility management protocol while avoiding the incompatibility and inefficiency problems listed in this document. Similarly, operators could decide to continue using one mobility management protocol throughout the period of IPv4 and IPv6 coexistence. However, a mobile node would be forced to choose one approach or the other, or nevertheless to install both and use one or the other according to circumstances.
IETFは、これらすべてのパスを追求することを選択した場合、ベンダーは、このドキュメントに記載されている非互換性と非効率性の問題を回避しながら、1つのモビリティ管理プロトコルをサポートすることを選択することができます。同様に、オペレータは、IPv4とIPv6の共存の期間を通して1つのモビリティ管理プロトコルを使用して継続することを決定することもできます。しかしながら、モバイルノードは、1つのアプローチを選択するように強制または他の、またはそれにもかかわらず、両方をインストールし、状況に応じてどちらか一方を使用することであろう。
This document is a problem statement that does not by itself introduce any security issues.
このドキュメントは、それ自体ではセキュリティ上の問題を導入していない問題文です。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmarkと、E.、 "ステートレスIP / ICMP翻訳アルゴリズム（SIIT）"、RFC 2765、2000年2月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[RFC4068] Koodli、R.、 "モバイルIPv6のための高速ハンドオーバ"、RFC 4068、2005年7月。
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
[RFC4140]ソリマン、H.、カステルッシア、C.、エルMalki、K.、およびL. Bellier、 "階層モバイルIPv6モビリティ・マネジメント（HMIPv6の）"、RFC 4140、2005年8月。
Authors' Addresses
著者のアドレス
George Tsirtsis Qualcomm
ジョージTsirtsisクアルコム
Phone: +908-443-8174 EMail: tsirtsis@qualcomm.com
電話：+ 908-443-8174 Eメール：tsirtsis@qualcomm.com
Hesham Soliman Elevate Technologies
ヒシャムスレイマン・テクノロジーズペスト
Phone: +614-111-410-445 EMail: hesham@elevatemobile.com
電話：+ 614-111-410-445 Eメール：hesham@elevatemobile.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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に情報を記述してください。