[要約] RFC 5096は、Mobile IPv6の実験的なメッセージに関する仕様を提供しています。このRFCの目的は、Mobile IPv6の実装やテストにおいて、新しいメッセージを使用するためのガイドラインを提供することです。
Network Working Group V. Devarapalli
Request for Comments: 5096 Azaire Networks
Category: Standards Track December 2007
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
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プロトコルの実験的拡張に使用できるモビリティオプションを定義します。
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
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]に示されています。
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.
このドキュメントでは、新しいモビリティヘッダーメッセージを定義します。これは、モバイルノード、ホームエージェント、または特派員ノードによっていつでも送信できる実験的モビリティメッセージです。モビリティヘッダーメッセージを1つのパケットに組み合わせて送信することはできないため、モバイルIPv6パケットには常にモビリティヘッダーメッセージが1つしかありません。モビリティメッセージタイプを認識しないホームエージェントまたは特派員ノードの実装は、メッセージを破棄し、[2]で説明されているように結合エラーメッセージを送信し、ステータスフィールドは2（認識されていないMHタイプ値）に設定されています。モビリティメッセージタイプを認識しないモバイルノードは、メッセージを破棄し、コード0にICMPパラメーターの問題を送信する必要があります。
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].
このドキュメントでは、新しいモビリティオプションである実験モビリティオプションも定義します。これは、あらゆるモビリティヘッダーメッセージに伝達できるものです。モビリティオプションは、実装がモビリティオプションタイプ[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.
このドキュメントで定義されているメッセージは、ネットワークモビリティ（NEMO）[4]およびプロキシモバイルIPv6 [5]にも使用できます。これらのプロトコルはモビリティヘッダーメッセージも使用しているためです。
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つずつ制限されます。実験メカニズムが有用であることが示されている場合、実験を超えてそれらを展開したいという欲求があり、標準化され、新しいコードポイントが与えられる必要があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[1]に記載されているとおりに解釈される。
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.
実験的モビリティヘッダーメッセージは、RFC 3775 [2]のセクション6.1で定義されているモビリティヘッダーメッセージに基づいています。モビリティヘッダーに必要なフィールドを超えてメッセージにフィールドはありません。モビリティヘッダーの「MHタイプ」フィールドは、実験的なモビリティヘッダーメッセージであることを示します。
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オクテットが除外されるため、0に設定されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See RFC 3775 [2] for a description of the 'Payload Proto', 'Header Len', 'MH Type', 'Reserved', and 'Checksum' fields.
「ペイロードプロト」、「ヘッダーレン」、「MHタイプ」、「予約済み」、および「チェックサム」フィールドの説明については、RFC 3775 [2]を参照してください。
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.
「メッセージデータ」フィールドには、実験的なプロトコル拡張に固有のデータが含まれます。メッセージの全長は、モビリティヘッダーの「ヘッダーレン」フィールドで示されます。
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.
実験的モビリティオプションは、モビリティヘッダーメッセージに含めることができます。モビリティヘッダーメッセージに拘束力のある承認データオプション[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 | Data .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
タイプと長さのフィールドを除くオクテットのオプションの長さを示す8ビットフィールド。
Data
データ
Data related to the experimental protocol extension.
実験プロトコル拡張に関連するデータ。
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.
実験的モビリティヘッダーメッセージとモビリティオプションの保護は、実行されている実験と、メッセージ内で実行されている情報の種類に依存します。これらのメッセージが、ワイヤーで明らかにされるべきではない情報を持ち、ホームエージェントまたは特派員ノードのバインディングキャッシュエントリに影響を与える可能性がある場合、バインディングの更新と拘束力のある謝辞と同様の方法で保護する必要があります。
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].
実験コードポイントが管理上自己完結型ネットワークドメイン内に展開されている場合、実験間の干渉を避けるために、各コードポイントが一貫して使用されるようにする必要があります。複数の管理ドメインを通過するトラフィックで実験コードポイントが使用される場合、実験者は、他の実験によって同じコードポイントが同時に使用されるリスクがあり、実験が干渉する可能性があると仮定する必要があります。そのような干渉が生じるかもしれないセキュリティの脅威に特に注意を払うべきです。詳細については、RFC 4727を参照してください[6]。
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].
セクション3で定義されている実験的モビリティヘッダーメッセージは、モビリティヘッダー[2]の「MHタイプ」フィールドと同じスペースから割り当てられたタイプ値（11）が割り当てられています。
The Experimental Mobility option, defined in Section 4, has been assigned the type value (18), allocated from the same space as Mobility Options [2].
セクション4で定義されている実験的モビリティオプションには、モビリティオプションと同じスペースから割り当てられたタイプ値（18）が割り当てられています[2]。
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] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[3] Narten、T。、「有用と見なされる実験数とテスト数の割り当て」、BCP 82、RFC 3692、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.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、RFC 3963、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] Fenner、B。、「IPv4、IPv6、ICMPV4、ICMPV6、UDP、およびTCPヘッダーの実験値」、RFC 4727、2006年11月。
Author's Address
著者の連絡先
Vijay Devarapalli Azaire Networks 4800 Great America Pkwy Santa Clara, CA 95054 USA
Vijay Devarapalli Azaire Networks 4800 Great America Pkwy Santa Clara、CA 95054 USA
EMail: vijay.devarapalli@azairenet.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への情報をお問い合わせください。