RFC5096 日本語訳
5096 Mobile IPv6 Experimental Messages. V. Devarapalli. December 2007. (Format: TXT=13669 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Devarapalli Request for Comments: 5096 Azaire Networks Category: Standards Track December 2007
Devarapalliがコメントのために要求するワーキンググループV.をネットワークでつないでください: 5096Azaireはカテゴリをネットワークでつなぎます: 標準化過程2007年12月
Mobile IPv6 Experimental Messages
モバイル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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document defines a new experimental Mobility Header message and a Mobility option that can be used for experimental extensions to the Mobile IPv6 protocol.
このドキュメントは実験的な拡大にモバイルIPv6プロトコルに使用できる新しい実験Mobility HeaderメッセージとMobilityオプションを定義します。
Table of Contents
目次
1. Introduction ....................................................1
2. Terminology .....................................................2
3. Experimental Mobility Header Message ............................3
4. Experimental Mobility Option ....................................3
5. Security Considerations .........................................4
6. IANA Considerations .............................................5
7. Acknowledgements ................................................5
8. References ......................................................5
8.1. Normative References .......................................5
8.2. Informative References .....................................5
1. 序論…1 2. 用語…2 3. 実験移動性ヘッダーメッセージ…3 4. 実験的な移動性オプション…3 5. セキュリティ問題…4 6. IANA問題…5 7. 承認…5 8. 参照…5 8.1. 標準の参照…5 8.2. 有益な参照…5
1. Introduction
1. 序論
When experimenting with a protocol or defining a new extension to a protocol, one needs either a protocol number, a new message, or an option to carry the information related to the experiment. Most implementations end up using unassigned values for the new messages. Many times this creates problems when the same value is assigned through the IETF standards action, by IANA, or if the implementation gets deployed with these messages. Therefore, it is considered a good practice to set aside some code points that identify the experimental protocols or messages for experimental purposes. The need for experimental messages is shown in [3].
プロトコルを実験するか、または新しい拡大をプロトコルと定義するとき、人は、実験に関連する情報を運ぶためにプロトコル番号、新しいメッセージ、またはオプションを必要とします。 ほとんどの実装が結局、新しいメッセージに割り当てられなかった値を使用します。 同じ値がIETF規格動作で割り当てられるとき、何回も、これは問題を生じさせます、IANAかそれとも実装がこれらのメッセージで配布されるかどうかによって。 したがって、それは、実験目的のために実験プロトコルかメッセージを特定するいくつかのコード・ポイントをかたわらに置くために良い習慣であると考えられます。 実験メッセージの必要性は[3]に示されます。
Devarapalli Standards Track [Page 1] RFC 5096 MIPv6 Experimental Messages December 2007
メッセージ2007年12月に実験的なDevarapalli標準化過程[1ページ]RFC5096MIPv6
This document defines new messages for experimenting with extensions to the Mobile IPv6 protocol. These messages should be strictly used for experiments. Experiments that are successful should be standardized in the IETF. An implementation MUST NOT be released or deployed with the experimental messages.
このドキュメントはモバイルIPv6プロトコルに拡大を実験することへの新しいメッセージを定義します。 これらのメッセージは実験に厳密に使用されるべきです。 うまくいっている実験はIETFで標準化されるべきです。 実験メッセージで実装を、リリースされてはいけないか、配布してはいけません。
This document defines a new Mobility Header message, which is the Experimental Mobility message that can be sent at any time by the mobile node, the home agent or the correspondent node. Since Mobility Header messages cannot be combined and sent in one packet, there is always only one Mobility Header message in any Mobile IPv6 packet. Home agent or correspondent node implementations that do not recognize the mobility message type, discard the message and send a Binding Error message as described in [2], with the Status field set to 2 (unrecognized MH Type value). Mobile nodes that do not recognize the mobility message type should discard the message and send an ICMP Parameter problem with code 0.
このドキュメントは新しいMobility Headerメッセージを定義します。(それは、いつでもモバイルノード、ホームのエージェントまたは通信員ノードで送ることができるExperimental Mobilityメッセージです)。 1つのパケットでMobility Headerメッセージを結合して、送ることができないので、1つのMobility HeaderメッセージしかどんなモバイルIPv6パケットにもいつもありません。 移動性メッセージを認めないホームのエージェントか通信員ノード実装が、[2]で説明されるようにタイプして、メッセージを捨てて、Binding Errorメッセージを送ります、2(認識されていないMH Type値)に設定されたStatus分野で。 移動性メッセージタイプを見分けないモバイルノードは、コード0と共にメッセージを捨てて、ICMP Parameter問題を送るはずです。
This document also defines a new mobility option, the Experimental Mobility option, which can be carried in any Mobility Header message. Mobility options, by definition, can be skipped if an implementation does not recognize the mobility option type [2].
また、このドキュメントは新しい移動性オプション、どんなMobility Headerメッセージでも運ぶことができるExperimental Mobilityオプションを定義します。 実装が移動性オプションタイプ[2]を見分けないなら、定義上移動性オプションをサボることができます。
The messages defined in this document can also be used for Network Mobility (NEMO) [4] and Proxy Mobile IPv6 [5] since these protocols also use Mobility Header messages.
また、[5] また、これらのプロトコルがMobility Headerメッセージを使用するので、Network Mobility(ネモ)[4]とProxyのモバイルIPv6に本書では定義されたメッセージは使用できます。
Experimental code points could potentially disrupt a deployed network when experiments using these code points are performed in the network. Therefore, the network scope of support for experimental values should carefully be evaluated before deploying any experiment across extended network domains, such as the public Internet.
これらのコード・ポイントを使用する実験がネットワークで行われるとき、実験コード・ポイントは潜在的に配布しているネットワークを混乱させるかもしれません。 したがって、拡大ネットワークドメインの向こう側にどんな実験も配布する前に実験値のサポートのネットワーク範囲は慎重に評価されるべきです、公共のインターネットなどのように。
Experimental mechanisms should only be used for actual experimentation. By design, only a single code point is allocated for the message and another one for the option. This limits the number of experiments among a set of peers to one at a time. When experimental mechanisms are shown to be useful, and there is a desire to deploy them beyond the experiment they should be standardized and given new code points.
実験メカニズムは実際の実験に使用されるだけであるべきです。 故意に、オプションのためのメッセージと別の1つのために1コード・ポイントだけを割り当てます。 これは1セットの同輩の中で実験の数を一度に一つ制限します。 いつ、実験メカニズムが役に立つように見せられて、標準化されて、それらが実験であるべきであることを超えてそれらを配布する願望があるか、そして、与えられた新法は指します。
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]で説明されるように本書では解釈されることであるべきですか?
Devarapalli Standards Track [Page 2] RFC 5096 MIPv6 Experimental Messages December 2007
メッセージ2007年12月に実験的なDevarapalli標準化過程[2ページ]RFC5096MIPv6
3. Experimental Mobility Header Message
3. 実験移動性ヘッダーメッセージ
The Experimental Mobility Header message is based on the Mobility Header message defined in Section 6.1 of RFC 3775 [2]. There are no fields in the message beyond the required fields in the Mobility Header. The 'MH Type' field in the Mobility Header indicates that it is an Experimental Mobility Header message.
Experimental Mobility HeaderメッセージはRFC3775[2]のセクション6.1で定義されたMobility Headerメッセージに基づいています。 必須項目を超えて分野は全くMobility Headerにメッセージでいません。 Mobility Headerの'MH Type'分野は、それがExperimental Mobility Headerメッセージであることを示します。
If no data is present in the message, two bytes of padding are required. The 'Header Len' field in the Mobility Header is set to 0 since the first 8 octets are excluded while calculating the length of the Mobility Header message.
どんなデータもメッセージに存在していないなら、2バイトの詰め物が必要です。 最初の8つの八重奏がMobility Headerメッセージの長さについて計算している間、除かれるので、Mobility Headerの'ヘッダーレン'分野は0に設定されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効搭載量プロト| ヘッダーレン| MHはタイプします。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . メッセージデータ…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See RFC 3775 [2] for a description of the 'Payload Proto', 'Header Len', 'MH Type', 'Reserved', and 'Checksum' fields.
'有効搭載量プロト'の記述のためのRFC3775[2]、'ヘッダーレン'、'MH Type'が'予約し'て、'チェックサム'がさばくのを確実にしてください。
The 'Message Data' field carries the data specific to the experimental protocol extension. The total length of the message is indicated by the 'Header Len' field in the Mobility Header.
'メッセージData'分野は実験的なプロトコル拡大に特定のデータを運びます。 メッセージの全長はMobility Headerの'ヘッダーレン'分野によって示されます。
4. Experimental Mobility Option
4. 実験的な移動性オプション
The Experimental Mobility option can be included in any Mobility Header message. If the Mobility Header message includes a Binding Authorization Data option [2], then the Experimental Mobility option should appear before the Binding Authorization Data option.
どんなMobility HeaderメッセージにもExperimental Mobilityオプションを含むことができます。 Mobility HeaderメッセージがBinding Authorization Dataオプション[2]を含んでいるなら、Experimental MobilityオプションはBinding Authorization 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Devarapalli Standards Track [Page 3] RFC 5096 MIPv6 Experimental Messages December 2007
メッセージ2007年12月に実験的なDevarapalli標準化過程[3ページ]RFC5096MIPv6
Type
タイプ
An 8-bit field indicating that it is an experimental mobility
option.
それが実験的な移動性オプションであることを示す8ビットの分野。
Length
長さ
An 8-bit field indicating the length of the option in octets
excluding the Type and Length fields.
Typeを除いた八重奏における、オプションの長さを示す8ビットの分野とLength分野。
Data
データ
Data related to the experimental protocol extension.
データは実験的なプロトコル拡大に関連しました。
5. Security Considerations
5. セキュリティ問題
Protection for the Experimental Mobility Header message and Mobility option depends on the experiment that is being carried out and the kind of information that is being carried in the messages. If these messages carry 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, they should be protected in a manner similar to Binding Updates and Binding Acknowledgements.
Experimental Mobility HeaderメッセージとMobilityオプションのための保護は行われている実験とメッセージで運ばれる情報の種類に依存します。 これらのメッセージがワイヤで明らかにされるべきでないか、またはホームのエージェントか通信員ノードで拘束力があるキャッシュエントリーに影響できる情報を運ぶなら、それらはBinding UpdatesとBinding Acknowledgementsと同様の方法で保護されるべきです。
Security analyzers such as firewalls and network intrusion detection monitors often rely on unambiguous interpretations of the fields described in this document. As new values for the fields are assigned, existing security analyzers that do not understand the new values may fail, resulting in either loss of connectivity, if the analyzer declines to forward the unrecognized traffic, or in loss of security if it does forward the traffic and the new values are used as part of an attack.
ファイアウォールやネットワーク侵入検出モニターなどのセキュリティ分析器はしばしば本書では説明された分野の明白な解釈に依存します。 分野への新しい値が割り当てられるとき、新しい値を理解していない既存のセキュリティ分析器は失敗するかもしれません、接続性の損失をもたらして、分析器が、認識されていないトラフィックを進めるのが下落させるか、または前方にするならセキュリティの損失に、トラフィックと新しい値が攻撃の一部として使用されるなら。
When experimental code points are deployed within an administratively self-contained network domain, it must be ensured that each code point is used consistently to avoid interference between experiments. When experimental code points are used in traffic that crosses multiple administrative domains, the experimenters should assume that there is a risk that the same code points will be used simultaneously by other experiments and that there is a possibility that the experiments will interfere. Particular attention should be given to security threats that such interference might create. Please see RFC 4727 for more details [6].
実験コード・ポイントが行政上自己充足的なネットワークドメインの中で配布されるとき、各コード・ポイントが実験の間の干渉を避けるのに一貫して使用されるのを確実にしなければなりません。 実験コード・ポイントがトラフィックに使用されるときの同じコードが指す危険が同時に、他の実験で使用されて、実験に干渉する可能性があるという十字倍数管理のドメインであり、実験者がそこでそれを仮定するべきであるのによることです。 そのような干渉が作成するかもしれない軍事的脅威に特別の注意を与えるべきです。 その他の詳細[6]に関してRFC4727を見てください。
Devarapalli Standards Track [Page 4] RFC 5096 MIPv6 Experimental Messages December 2007
メッセージ2007年12月に実験的なDevarapalli標準化過程[4ページ]RFC5096MIPv6
6. IANA Considerations
6. IANA問題
The Experimental Mobility Header message, defined in Section 3, has been assigned the type value (11), allocated from the same space as the 'MH Type' field in the Mobility Header [2].
Mobility Header[2]に'MH Type'分野と同じスペースから割り当てられたタイプ値(11)をセクション3で定義されたExperimental Mobility Headerメッセージに割り当ててあります。
The Experimental Mobility option, defined in Section 4, has been assigned the type value (18), allocated from the same space as Mobility Options [2].
Mobility Options[2]と同じスペースから割り当てられたタイプ値(18)をセクション4で定義されたExperimental Mobilityオプションに割り当ててあります。
7. Acknowledgements
7. 承認
The author would like to thank Jari Arkko and Basavaraj Patil with whom the contents of this document were discussed first.
作者は最初にこのドキュメントのコンテンツについて議論したヤリArkkoとBasavarajパティルに感謝したがっています。
8. References
8. 参照
8.1. Normative References
8.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月の移動性サポート。」
8.2. Informative References
8.2. 有益な参照
[3] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[3]Narten、T.、「役に立つと考えられた実験的でテストしている数を割り当てます」、BCP82、RFC3692、2004年1月。
[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[4]Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP.Thubert、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、2005年1月。
[5] Gundavelli, S., "Proxy Mobile IPv6", Work in Progress, March
2007.
[5]Gundavelli、S.、「プロキシのモバイルIPv6"、処理中の作業、2007年3月。」
[6] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6,
UDP, and TCP Headers", RFC 4727, November 2006.
[6] フェナー、B.、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC4727、2006年11月。
Devarapalli Standards Track [Page 5] RFC 5096 MIPv6 Experimental Messages December 2007
メッセージ2007年12月に実験的なDevarapalli標準化過程[5ページ]RFC5096MIPv6
Author's Address
作者のアドレス
Vijay Devarapalli Azaire Networks 4800 Great America Pkwy Santa Clara, CA 95054 USA
ビジェイDevarapalli Azaireは4800グレート・アメリカPkwyカリフォルニア95054サンタクララ(米国)をネットワークでつなぎます。
EMail: vijay.devarapalli@azairenet.com
メール: vijay.devarapalli@azairenet.com
Devarapalli Standards Track [Page 6] RFC 5096 MIPv6 Experimental Messages December 2007
メッセージ2007年12月に実験的なDevarapalli標準化過程[6ページ]RFC5096MIPv6
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に情報を扱ってください。
Devarapalli Standards Track [Page 7]
Devarapalli標準化過程[7ページ]
一覧
スポンサーリンク
