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
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）IETFトラスト（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.
この文書で定義されたメッセージは、[4]これらのプロトコルはまた、モビリティヘッダのメッセージを使用するので、NEMO [3]及びプロキシMIPv6のためにも使用することができます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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-維持民間企業番号レジストリのSMIネットワーク管理プライベートエンタープライズコード[5]。
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.
著者は、この文書の内容は最初に議論された誰とヤリArkkoとBasavarajパティルに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[2]ジョンソン、D.、パーキンス、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.、ペトレスク、A.、およびP. Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、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割り当て番号オンラインデータベース、 "民間企業番号"、<http://www.iana.org/assignments/enterprise-numbers>。
Authors' Addresses
著者のアドレス
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA
ビジェイDevarapalli Azaireネットワーク3121ジェイ・ストリートサンタクララ、CA 95054 USA
EMail: vijay.devarapalli@azairenet.com
メールアドレス：vijay.devarapalli@azairenet.com
Alpesh Patel Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Alpeshパテルシスコ170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: alpesh@cisco.com
メールアドレス：alpesh@cisco.com
Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA
ケント・レオンのCisco 170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: kleung@cisco.com
メールアドレス：kleung@cisco.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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。