RFC5094 日本語訳
5094 Mobile IPv6 Vendor Specific Option. V. Devarapalli, A. Patel, K.Leung. December 2007. (Format: TXT=11430 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Devarapalli
Request for Comments: 5094 Azaire Networks
Category: Standards Track A. Patel
K. Leung
Cisco
December 2007
Devarapalliがコメントのために要求するワーキンググループV.をネットワークでつないでください: 5094Azaireはカテゴリをネットワークでつなぎます: 標準化過程A.パテルK.レオンコクチマス2007年12月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
Mobility Headerメッセージへのベンダー特有の拡大の必要があるので、モバイル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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 ベンダー特有の移動性オプション. . . . . . . . . . . . . . . . 3 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 4 5。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 4 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 4 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 5 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 5
Devarapalli, et al. Standards Track [Page 1] RFC 5094 MIPv6 Vendor Specific Option December 2007
Devarapalli、他 オプション2007年12月に特定の標準化過程[1ページ]RFC5094MIPv6ベンダー
1. Introduction
1. 序論
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.
ベンダー特有のメッセージで、ベンダーは、いくつかのプロトコルに拡大を実装して、他のベンダーと自分たちを伝統的に区別しました。 これらのメッセージはベンダーを特定するVendor IDによって明確にマークされます。 特定のベンダーの実装は、Vendor IDを認識することによって、ベンダー拡大を特定します。 Vendor 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]は配布されています、そして、Mobility Headerメッセージへのベンダーの特定の拡大の必要があるので、ベンダーは研究か展開目的のためにモバイル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].
このドキュメントは新しい移動性オプション、どんなMobility Headerメッセージでも運ぶことができるVendor特有のMobility Optionを定義します。 Mobility Headerメッセージだけと共にVendor特有の移動性オプションを使用しなければなりません。 実装が移動性オプションタイプ[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] また、これらのプロトコルがMobility Headerメッセージを使用するので、ネモ[3]とProxy 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交換処理に追加データを背負うことができますが、RFC3775[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レビューと標準化に依存しているのを示しました。
Devarapalli, et al. Standards Track [Page 2] RFC 5094 MIPv6 Vendor Specific Option December 2007
Devarapalli、他 オプション2007年12月に特定の標準化過程[2ページ]RFC5094MIPv6ベンダー
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?
3. Vendor-Specific Mobility Option
3. ベンダー特有の移動性オプション
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.
Vendor Specific Mobility OptionはどんなMobility Headerメッセージにも含むことができて、4n+2の整列要求を持っています。 Mobility HeaderメッセージがBinding Authorization Dataオプション[2]を含んでいるなら、Vendor Specific移動性オプションはBinding Authorization Dataオプションの前に現れるべきです。 複数のVendor特有の移動性オプションがMobility Headerメッセージに存在しているかもしれません。
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.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダーID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブタイプ| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
An 8-bit field indicating that it is a Vendor-Specific mobility
option.
それがVendor特有の移動性オプションであることを示す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.
Typeを除いた八重奏における、オプションの長さを示す8ビットの分野とLength分野。 他のすべての分野が含まれています。
Vendor ID
ベンダーID
The SMI Network Management Private Enterprise Code of the IANA-
maintained Private Enterprise Numbers registry [5].
兵士のエンタープライズであることが支持されたIANA民数記登録[5]のSMI Network Management兵士のエンタープライズCode。
Devarapalli, et al. Standards Track [Page 3] RFC 5094 MIPv6 Vendor Specific Option December 2007
Devarapalli、他 オプション2007年12月に特定の標準化過程[3ページ]RFC5094MIPv6ベンダー
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ビットの野原はオプションで運ばれました。 VendorはSub-タイプの管理を完了しています。
Data
データ
Vendor-specific data that is carried in this message.
このメッセージで運ばれるベンダー特有のデータ。
4. Security Considerations
4. セキュリティ問題
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.
ワイヤで明らかにされるべきでないか、またはホームのエージェントか通信員ノードで拘束力があるキャッシュエントリーに影響できる情報を運ぶなら、Vendor特有の移動性メッセージはBinding UpdatesとBinding Acknowledgementsと同様の方法で保護されるべきです。 Vendor Specific移動性オプションを含むメッセージは特に、保護された保全であるに違いありません。
5. IANA Considerations
5. IANA問題
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].
RFC3775[2]によって作成されたMobility Options登録と同じスペースから割り当てられたタイプ値(19)をセクション3で定義されたVendor特有の移動性オプションに割り当ててあります。
6. Acknowledgements
6. 承認
The author would like to thank Jari Arkko and Basavaraj Patil with whom the contents of this document were discussed first.
作者は最初にこのドキュメントのコンテンツについて議論したヤリArkkoとBasavarajパティルに感謝したがっています。
Devarapalli, et al. Standards Track [Page 4] RFC 5094 MIPv6 Vendor Specific Option December 2007
Devarapalli、他 オプション2007年12月に特定の標準化過程[4ページ]RFC5094MIPv6ベンダー
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
7.2. Informative References
7.2. 有益な参照
[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、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、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/課題/番号>を割り当てました。
Devarapalli, et al. Standards Track [Page 5] RFC 5094 MIPv6 Vendor Specific Option December 2007
Devarapalli、他 オプション2007年12月に特定の標準化過程[5ページ]RFC5094MIPv6ベンダー
Authors' Addresses
作者のアドレス
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA
ビジェイDevarapalli Azaireは3121ジェイ・通りカリフォルニア95054サンタクララ(米国)をネットワークでつなぎます。
EMail: vijay.devarapalli@azairenet.com
メール: vijay.devarapalli@azairenet.com
Alpesh Patel Cisco 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・Drive Alpeshパテルシスコ170カリフォルニア95134サンノゼ(米国)
EMail: alpesh@cisco.com
メール: alpesh@cisco.com
Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA
レオンシスコ170の西タスマン・Driveケントカリフォルニア95134サンノゼ(米国)
EMail: kleung@cisco.com
メール: kleung@cisco.com
Devarapalli, et al. Standards Track [Page 6] RFC 5094 MIPv6 Vendor Specific Option December 2007
Devarapalli、他 オプション2007年12月に特定の標準化過程[6ページ]RFC5094MIPv6ベンダー
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Devarapalli, et al. Standards Track [Page 7]
Devarapalli、他 標準化過程[7ページ]
一覧
スポンサーリンク
