[要約] RFC 4977は、Dual Stack Mobilityの問題と目的について説明しています。Dual Stack Mobilityは、IPv4とIPv6の両方をサポートするモバイルネットワークでの移動性の問題を解決することを目的としています。
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.
このドキュメントでは、デュアルスタックモバイルノードのモビリティ管理に関連する問題について説明します。現在、IPv4とIPv6に対して2つのモビリティ管理プロトコルが定義されています。両方をデュアルスタックモバイルノードに展開すると、多くの問題が導入されます。展開と運用上の問題は、単一のモビリティ管理プロトコルの使用をやる気にさせます。このドキュメントでは、そのような動機について説明します。このドキュメントでは、モバイル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.
このドキュメントでは、Stateless IP/ ICMP翻訳（SIIT）[RFC2765]で定義されている次の用語を使用します。IPv4対応ノード、IPv4対応ノード、IPv6対応ノード、IPv6対応ノード。
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 [RFC3344]を使用して、IPv4サブネット間を移動しながら接続性を維持できます。同様に、MIPV6-対応のノードは、モバイルIPv6 [RFC3775]を使用して、IPv6サブネット間を移動しながら接続性を維持できます。
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に移行する方法の1つは、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スタックにモバイルIPv4とIPv6スタックにモバイルIPv6を使用して、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.
- ハンドオフごとに2セットの信号メッセージを送信するモバイルノード。
- 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]のバインディングアップデート）を使用して、2つのエンドポイント間にトンネルをセットアップします。現時点では、モバイル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).
- モバイルノードとホームエージェントの構成の量を2倍にします（例：セキュリティ協会）。
- 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.
モバイルノードがデュアルスタックアクセスネットワーク内で移動していると仮定します。モバイルノードが移動するたびに、2つのモバイルIPメッセージをホームエージェントに送信して、IPv4とIPv6の接続が生き残ることができます。そのような複製の理由はありません。ローカルモビリティの最適化が展開された場合（例：階層モバイルIPv6（HMIPV6）[RFC4140]、モバイルIPv4の高速ハンドオーバー[RFC4068]）、モバイルノードは各プロトコルを実行しているローカルエージェントを更新する必要があります。皮肉なことに、1人のローカルエージェントがHMIPV6とローカルMIPV4ホームエージェントの両方を実行している可能性があります。明らかに、同じ基本的な最適化のために2つのメッセージを送信し、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が展開されると予想されるため、IPv4モビリティ管理からIPv6への徐々に移行する必要があります。両方のプロトコルを同時に実行することは非効率的であり、上記の問題があります。段階的な遷移は、必要なときに行うか、オペレーターまたは実装者が適切とみなすことができます。それまでの間、上記の問題を回避できることを確認することが重要です。したがって、このセクションには、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に作成して、IPv4およびIPv6対応のモバイルノードがIPv4およびIPv6ホームアドレスをMIPv6シグナル伝達のみを使用してIPv4-およびIPv6対応のホームエージェントに登録できるようにすることができるはずです。
- 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拡張機能をモバイルIPv4に作成して、IPv4およびIPv6対応のモバイルノードがIPv4およびIPv6ホームアドレスをモバイルIPv4シグナリングのみを使用して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.
- また、MIPV4 [RFC3344]とMIPV6 [RFC3775]を拡張して、モバイルノードがIPv4および/またはIPv6パケットをトンネルにすることができる単一のアドレス（IPv4またはIPv6）を登録できるようにすることも可能です。
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つのモビリティ管理プロトコルを使用し続けることを決定できます。ただし、モバイルノードは、いずれかのアプローチを選択することを余儀なくされるか、それにもかかわらず、両方のアプローチをインストールして、状況に応じてどちらかを使用することを余儀なくされます。
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。、「Stateless IP/ICMP翻訳アルゴリズム（SIIT）」、RFC 2765、2000年2月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、C。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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] Soliman、H.、Castelluccia、C.、El Malki、K。、およびL. Bellier、「階層モバイルIPv6モビリティ管理（HMIPV6）」、RFC 4140、2005年8月。
Authors' Addresses
著者のアドレス
George Tsirtsis Qualcomm
Phone: +908-443-8174
EMail: tsirtsis@qualcomm.com
Hesham Soliman Elevate Technologies
Hesham Soliman Elevate Technologies
Phone: +614-111-410-445
EMail: hesham@elevatemobile.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。