[要約] RFC 5094は、Mobile IPv6ベンダー固有オプションに関する仕様であり、モバイルノードの動作をカスタマイズするためのオプションを提供します。このRFCの目的は、モバイルIPv6の実装におけるベンダー固有の機能をサポートするための標準化を促進することです。
Network Working Group V. Devarapalli
Request for Comments: 5094 Azaire Networks
Category: Standards Track A. Patel
K. Leung
Cisco
December 2007
Mobile IPv6 Vendor Specific Option
モバイルIPv6ベンダー固有のオプション
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
There is a need for vendor-specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor-specific mobility option.
モバイルIPv6ベンダーが研究または展開の目的でプロトコルを拡張できるように、モビリティヘッダーメッセージに対するベンダー固有の拡張機能が必要です。このドキュメントでは、新しいベンダー固有のモビリティオプションを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Vendor-Specific Mobility Option . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Vendor-specific messages have traditionally allowed vendors to implement extensions to some protocols and distinguish themselves from other vendors. These messages are clearly marked by a Vendor ID that identifies the vendor. A particular vendor's implementation identifies the vendor extension by recognizing the Vendor ID. Implementations that do not recognize the Vendor ID either discard or skip processing the message.
ベンダー固有のメッセージは、従来、ベンダーがいくつかのプロトコルに拡張機能を実装し、他のベンダーと区別することを許可していました。これらのメッセージは、ベンダーを識別するベンダーIDによって明確にマークされています。特定のベンダーの実装は、ベンダーIDを認識することにより、ベンダー拡張機能を識別します。ベンダーIDがメッセージを破棄またはスキップすることを認識しない実装。
Mobile IPv6 [2] is being deployed and there is a need for vendor-specific extensions to Mobility Header messages so that vendors are able to extend the Mobile IPv6 protocol for research or deployment purposes.
モバイルIPv6 [2]は展開されており、ベンダー固有の拡張機能がモビリティヘッダーメッセージに必要であるため、ベンダーは研究または展開の目的でモバイルIPv6プロトコルを拡張できるようにします。
This document defines a new mobility option, the Vendor-Specific Mobility Option, which can be carried in any Mobility Header message. The Vendor-Specific mobility option MUST be used only with a Mobility Header message. Mobility options, by definition, can be skipped if an implementation does not recognize the mobility option type [2].
このドキュメントでは、新しいモビリティオプションであるベンダー固有のモビリティオプションを定義します。これは、あらゆるモビリティヘッダーメッセージで伝えることができます。ベンダー固有のモビリティオプションは、モビリティヘッダーメッセージでのみ使用する必要があります。モビリティオプションは、実装がモビリティオプションタイプ[2]を認識しない場合はスキップできます。
The messages defined in this document can also be used for NEMO [3] and Proxy MIPv6 [4] since these protocols also use Mobility Header messages.
このドキュメントで定義されているメッセージは、Nemo [3]およびProxy Mipv6 [4]にも使用できます。これらのプロトコルはモビリティヘッダーメッセージも使用しているためです。
Vendor-specific protocol extensions can cause serious interoperability issues and may in addition have adverse operational impact, if they are not designed and used carefully. The vendor-specific option described in this document is meant to support simple use cases where it is sufficient to include some vendor data in the standardized Mobile IPv6 protocol exchanges. The vendor-specific option is not suitable for more complex vendor extensions that modify Mobile IPv6 itself. Although these options allow vendors to piggyback additional data onto Mobile IPv6 message exchanges, RFC 3775 [2] requires that unrecognized options be ignored and that the end systems be able to process the remaining parts of the message correctly. Extensions that use the vendor-specific mobility option should require an indication that the option was processed, in the response, using the vendor-specific mobility option.
ベンダー固有のプロトコル拡張は、深刻な相互運用性の問題を引き起こす可能性があり、さらに慎重に設計および使用されていない場合、操作上の悪影響を与える可能性があります。このドキュメントで説明されているベンダー固有のオプションは、標準化されたモバイルIPv6プロトコル交換にいくつかのベンダーデータを含めることが十分である簡単なユースケースをサポートすることを目的としています。ベンダー固有のオプションは、モバイルIPv6自体を変更するより複雑なベンダー拡張機能には適していません。これらのオプションにより、ベンダーはモバイルIPv6メッセージ交換に追加のデータを貯蔵することができますが、RFC 3775 [2]では、認識されていないオプションを無視し、最終システムでメッセージの残りの部分を正しく処理できることが必要です。ベンダー固有のモビリティオプションを使用する拡張機能には、ベンダー固有のモビリティオプションを使用して、応答でオプションが処理されたことを示す必要があります。
Vendors are generally encouraged to bring their protocol extensions to the IETF for review and standardization. Complex vendor extensions that modify Mobile IPv6 itself, will see large-scale deployment or involve industry consortia, or other multi-vendor organizations MUST be standardized in the IETF. Past experience has shown that such extensions of IETF protocols are critically dependent on IETF review and standardization.
ベンダーは一般に、レビューと標準化のためにプロトコル拡張機能をIETFに持ち込むことをお勧めします。モバイルIPv6自体を変更する、大規模な展開を確認する、または業界のコンソーシアムを含む複雑なベンダー拡張機能、または他のマルチベンダー組織をIETFに標準化する必要があります。過去の経験は、IETFプロトコルのこのような拡張がIETFのレビューと標準化に大きく依存していることを示しています。
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 [1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[1]に記載されているとおりに解釈される。
The Vendor Specific Mobility Option can be included in any Mobility Header message and has an alignment requirement of 4n+2. If the Mobility Header message includes a Binding Authorization Data option [2], then the Vendor Specific mobility option should appear before the Binding Authorization Data option. Multiple Vendor-Specific mobility options MAY be present in a Mobility Header message.
ベンダー固有のモビリティオプションは、任意のモビリティヘッダーメッセージに含めることができ、4n 2のアライメント要件があります。モビリティヘッダーメッセージに拘束力のある承認データオプション[2]が含まれている場合、拘束力のある認証データの前にベンダー固有のモビリティオプションが表示されるはずです。オプション。モビリティヘッダーメッセージには、複数のベンダー固有のモビリティオプションが存在する場合があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Data.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
An 8-bit field indicating that it is a Vendor-Specific mobility option.
ベンダー固有のモビリティオプションであることを示す8ビットフィールド。
Length
長さ
An 8-bit field indicating the length of the option in octets excluding the Type and the Length fields. All other fields are included.
タイプと長さのフィールドを除くオクテットのオプションの長さを示す8ビットフィールド。他のすべてのフィールドが含まれています。
Vendor ID
ベンダーID
The SMI Network Management Private Enterprise Code of the IANA-maintained Private Enterprise Numbers registry [5].
IANAが管理するプライベートエンタープライズ番号レジストリ[5]のSMIネットワーク管理プライベートエンタープライズコード。
Sub-type
サブタイプ
An 8-bit field indicating the type of vendor-specific information carried in the option. The administration of the Sub-type is done by the Vendor.
オプションに掲載されたベンダー固有の情報のタイプを示す8ビットフィールド。サブタイプの管理はベンダーによって行われます。
Data
データ
Vendor-specific data that is carried in this message.
このメッセージに掲載されているベンダー固有のデータ。
The Vendor-Specific mobility messages should be protected in a manner similar to Binding Updates and Binding Acknowledgements if it carries information that should not be revealed on the wire or that can affect the binding cache entry at the home agent or the correspondent node. In particular, the messages containing the Vendor Specific mobility option MUST be integrity protected.
ベンダー固有のモビリティメッセージは、ワイヤーで明らかにされるべきではない情報やホームエージェントまたは特派員ノードのバインディングキャッシュエントリに影響を与える可能性がある場合、バインディングの更新と拘束力のある謝辞と同様の方法で保護する必要があります。特に、ベンダー固有のモビリティオプションを含むメッセージは、整合性保護されている必要があります。
The Vendor-Specific mobility option, defined in Section 3, has been assigned the type value (19), allocated from the same space as the Mobility Options registry created by RFC 3775 [2].
セクション3で定義されているベンダー固有のモビリティオプションは、RFC 3775 [2]によって作成されたモビリティオプションレジストリと同じスペースから割り当てられたタイプ値（19）を割り当てられています。
The author would like to thank Jari Arkko and Basavaraj Patil with whom the contents of this document were discussed first.
著者は、この文書の内容について最初に議論されたJari ArkkoとBasavaraj Patilに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[2] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[3] Devarapalli、V.、Wakikawa、R.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、RFC 3963、2005年1月。
[4] Gundavelli, S., "Proxy Mobile IPv6", Work in Progress, March 2007.
[4] Gundavelli、S。、「プロキシモバイルIPv6」、2007年3月、進行中の作業。
[5] IANA Assigned Numbers Online Database, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers>.
[5] IANAは、数字をオンラインデータベース「プライベートエンタープライズ番号」を割り当てました。
Authors' Addresses
著者のアドレス
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara、CA 95054 USA
EMail: vijay.devarapalli@azairenet.com
Alpesh Patel Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Alpesh Patel Cisco 170 West Tasman Drive San Jose、CA 95134 USA
EMail: alpesh@cisco.com
Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Kent Leung Cisco 170 West Tasman Drive San Jose、CA 95134 USA
EMail: kleung@cisco.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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。