Network Working Group J. Kempf
Request for Comments: 4065 DoCoMo Labs USA
Category: Experimental July 2005
Instructions for Seamoby and
Experimental Mobility Protocol IANA Allocations
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
The Seamoby Candidate Access Router Discovery (CARD) protocol and the Context Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, Stream Control Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options. This document contains instructions to IANA about which allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols.
Seamoby候補アクセスルータ発見（CARD）プロトコルおよびコンテキスト転送プロトコル（CXTP）は、無線アクセスルータ間のIPハンドオーバを加速するために設計された実験的なプロトコルです。これらのプロトコルは、ICMPタイプおよびオプションのIANA割り当て、ストリーム制御伝送プロトコル（SCTP）ペイロードプロトコル識別子、ポート番号、および特定のフォーマットされたメッセージのオプションのレジストリを必要とします。この文書では、割り当てがSeamobyプロトコルのために必要とされているかについてのIANAへの指示が含まれています。それは他の実験のモビリティプロトコルが利用できるようにSeamobyためのICMPサブタイプの拡張形式は、さらに設計されており、SCTPポート番号は、他の実験モビリティプロトコルのために利用可能です。
Table of Contents
目次
1. Introduction.................................................. 2
2. Common IPv4 and IPv6 Allocations.............................. 2
3. IPv4 Allocations.............................................. 3
4. IPv6 Allocations.............................................. 3
5. Candidate Access Router Discovery Protocol Registries......... 3
6. Context Transfer Profile Type Registry........................ 5
7. Context Transfer Protocol Authorization Token Calculation
Algorithm..................................................... 5
8. ICMP Experimental Mobility Subtype Format and Registry........ 5
9. Utilization by Other Experimental Mobility Protocols.......... 6
10. Normative References.......................................... 6
11. Security Considerations....................................... 7
12. IANA Considerations........................................... 7
The Seamoby Candidate Access Router Discovery (CARD) protocol [RFC4066] and the Context Transfer Protocol (CXTP) [RFC4067] are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP options and type, SCTP Payload Protocol Identifiers, port numbers, and the establishment of registries for certain formatted message options. Because the protocols are experimental, there is no guarantee that they will ever see widespread deployment in their current form. Consequently, it is prudent to conserve Internet numbering resources that might be needed for other protocols that could see wider deployment. This document contains instructions to IANA for the Seamoby protocols. Additionally, the ICMP subtype extension format has been designed so that it could be used by other experimental mobility protocols.
Seamoby候補アクセスルータ発見（CARD）プロトコル[RFC4066]、コンテキスト転送プロトコル（CXTP）[RFC4067]は、無線アクセスルータとの間のIPハンドオーバを促進するように設計された実験的なプロトコルです。これらのプロトコルは、ICMPオプションとタイプ、SCTPペイロードプロトコル識別子、ポート番号、および特定のフォーマットされたメッセージのオプションのレジストリの確立のためのIANA割り当てを必要とします。プロトコルは実験的であるため、彼らはこれまで彼らの現在の形で広く展開を見るという保証はありません。したがって、より広い展開を見ることができる他のプロトコルのために必要となるかもしれない、インターネット番号リソースを節約することが賢明です。この文書では、SeamobyプロトコルのIANAへの指示が含まれています。それは他の実験のモビリティプロトコルで使用することができるように、また、ICMPサブタイプの拡張フォーマットが設計されています。
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 RFC 2119 [RFC2119]. Allocation policy names Specification Required, IETF Consensus Action, and Designated Expert are to be interpreted as described in RFC 2434 [RFC2434].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC2119]に記載されているように解釈されます。割り当てポリシー名仕様が必要で、IETFコンセンサスアクション、および指定専門家は、RFC 2434 [RFC2434]で説明したように解釈されるべきです。
IANA has assigned SCTP port numbers 5090 for use by [RFC4066] and 5091 for use of [RFC4067]. See Section 5.2.1 of [RFC4066] for a description of the inter-access router CARD protocol use of SCTP, and Section 3.1 of [RFC4067] for a description of the inter-access router CXTP use of SCTP.
IANAは[RFC4067]を使用するための[RFC4066]及び5091によって使用するためにSCTPポート番号5090を割り当てました。 SCTPの間のアクセスルータCARDプロトコルの使用の説明については、[RFC4066]のセクション5.2.1、およびSCTPの間のアクセスルータCXTP使用の説明については、[RFC4067]のセクション3.1を参照。
IANA has assigned ICMP type 41 for IPv4 identifying ICMP messages utilized by experimental mobility protocols such as Seamoby. See Section 5.1.1 of [RFC4066] for a description of experimental mobility CARD ICMP messages and Section 3.2 of [RFC4067] for the CXTP ICMP messages, specified by Seamoby. See Section 9 of this document for a description of the experimental mobility protocol ICMP subtype format and initial allocations.
IANAは、IPv4は、Seamobyなどの実験モビリティプロトコルによって利用されるICMPメッセージを識別するためのICMPタイプ41を割り当てました。 Seamobyで指定されたCXTP ICMPメッセージのための実験的なモビリティCARD ICMPメッセージと[RFC4067]の3.2節の説明については、[RFC4066]のセクション5.1.1を参照してください。実験的なモビリティプロトコルICMPサブタイプのフォーマットと初期割り当ての詳細については、このドキュメントのセクション9を参照してください。
IANA has assigned Mobile IPv4 Foreign Agent Discovery [RFC3344] option type codes for the following:
IANAは、次のためにモバイルIPv4外部エージェント発見[RFC3344]オプション・タイプ・コードが割り当てられています：
Code Purpose Reference
---------------------------------------------------------------------
137 CARD MN-AR signature option Section 6.4 of [RFC4066]
138 CARD Request option Section 5.1.2.1 of [RFC4066]
139 CARD Reply option Section 5.1.2.2 of [RFC4066]
IANA has assigned ICMP type code 150 for IPv6 identifying ICMP messages utilized by experimental mobility protocols such as Seamoby. See Section 5.1.1 of [RFC4066] for a description of experimental mobility CARD ICMP messages and Section 3.2 of [RFC4067] for the CXTP ICMP messages, specified by Seamoby. See Section 9 of this document for a description of the experimental mobility protocol subtype format and initial allocations.
IANAは、IPv6は、Seamobyなどの実験モビリティプロトコルによって利用されるICMPメッセージを識別するためのICMPタイプコード150を割り当てました。 Seamobyで指定されたCXTP ICMPメッセージのための実験的なモビリティCARD ICMPメッセージと[RFC4067]の3.2節の説明については、[RFC4066]のセクション5.1.1を参照してください。実験的なモビリティプロトコルのサブタイプのフォーマットと初期割り当ての詳細については、このドキュメントのセクション9を参照してください。
IANA has assigned IPv6 RFC 2461 Neighbor Discovery [RFC2461] option type codes for the following:
IANAは、次のIPv6 RFC 2461に近隣探索[RFC2461]オプション・タイプ・コードを割り当てました。
Code Purpose Reference
----------------------------------------------------------------
138 CARD Request option Section 5.1.2.1 of [RFC4066]
139 CARD Reply option Section 5.1.2.2 of [RFC4066]
For CARD, two new registries are created that IANA is to maintain, named:
カード用の2つの新しいレジストリは、IANAが維持することであることを作成した名前が付けられます。
1) The AVP Type Registry, 2) The Layer 2 Access Technology Identifier Registry.
1）AVPタイプレジストリ、2）レイヤ2アクセス技術識別子レジストリ。
These are described in the following subsections.
これらは、以下のサブセクションで説明されています。
The AVP Type Registry allows for future expansion of the CARD AVP type space to include new AVPs. AVP Type codes are 16 bit unsigned integers. See Section 5.1.4 of [RFC4066] for a description of AVPs.
AVPタイプレジストリは、新しいAVPを含めるようにCARD AVPタイプ空間の将来の拡張が可能になります。 AVPタイプ・コードは、16ビットの符号なし整数です。 AVPの説明については、[RFC4066]のセクション5.1.4を参照してください。
The registry SHALL be initially populated with the following table:
レジストリは、最初に次の表が取り込まなければなりません。
AVP Name Type Code
----------------------------------------------
RESERVED 0x00
Future allocations of AVP type codes will be made through Expert Review, as defined in RFC 2434.
RFC 2434で定義されているAVP型コードの将来の割り当ては、専門家レビューを通じて行われます。
The Layer 2 Access Technology Identifier registry allows the registration of type codes to uniquely identify specific access technologies in the L2-Type field of the CARD L2 ID sub-option. L2 ID codes are 16 bit unsigned integers. See Section 5.1.3.1 of [RFC4066] for a description of the CARD L2 ID sub-option.
レイヤ2アクセス技術識別子レジストリは、タイプ・コードの登録を一意CARD L2 IDサブオプションのL2-Typeフィールドに特定のアクセス技術を識別することを可能にします。 L2のIDコードは、16ビットの符号なし整数です。 CARD L2 IDサブオプションの説明については、[RFC4066]のセクション5.1.3.1を参照してください。
The registry SHALL initially be populated with the following table:
レジストリは、最初に次の表が取り込まなければなりません。
Layer 2 Access Technology Type Code
----------------------------------------------
RESERVED 0x00
IEEE 802.3 (Ethernet) 0x01
IEEE 802.11a 0x02
IEEE 802.11b 0x03
IEEE 802.11g 0x04
IEEE 802.15.1(Bluetooth) 0x05
IEEE 802.15.3 0x06
IEEE 802.15.4 0x07
IEEE 802.16 0x08
Future allocation of Layer 2 Access Technology identifiers will be made by the method of Specification Required, as defined in RFC 2434. All requests for allocations MUST be accompanied by a reference to a technical document in which the design of the Layer 2 access technology is described.
配分のためのすべての要求は、レイヤ2アクセス技術の設計が記載された技術文書を参照して添付しなければならないRFC 2434で定義されているレイヤ2アクセス技術識別子の将来の割り当ては、仕様が必要の方法で行われます。
CXTP requires IANA to maintain a registry named the Context Transfer Profile Type Registry, which is a registry of context Feature Profile Type identifiers. Feature Profile Type identifiers are 16 bit unsigned integers that identify particular types of feature contexts. See Section 2.4 of [RFC4067] for a description of how contexts are carried in CXTP.
CXTPは、コンテキスト機能プロファイルタイプ識別子のレジストリであるコンテキスト転送プロファイルの種類レジストリという名前のレジストリを維持するために、IANAが必要です。機能プロファイルタイプ識別子は、機能コンテキストの特定のタイプを識別する16ビットの符号なし整数です。コンテキストはCXTPで運ばれる方法の詳細については、[RFC4067]の2.4節を参照してください。
The registry SHALL initially be populated with the following table:
レジストリは、最初に次の表が取り込まなければなりません。
Context Profile Type Code
----------------------------------------------
RESERVED 0x00
IPv6 Multicast Listener Context 0x01
Future allocations of Feature Profile Type codes will be made through Expert Review, as defined in RFC 2434.
RFC 2434で定義されている機能のプロファイルタイプ・コードの今後の割り当ては、専門家レビューを通じて行われます。
In Section 2.5.4 of [RFC4067], CXTP requires an authorization token calculation algorithm indicator. Currently, the only indicator defined is 0x1, for HMAC_SHA1. Additional algorithms may be added by the method of Specification Required [RFC2434].
[RFC4067]のセクション2.5.4において、CXTPは、許可トークン計算アルゴリズムインジケータを必要とします。現在、定義された唯一のインジケータがHMAC_SHA1ため、0x1のです。追加のアルゴリズムは、仕様が必要[RFC2434]の方法により添加してもよいです。
The ICMP Experimental Mobility Type is utilized by CARD and CXTP in the following way. The interpretation of the Code field is as defined by the relevant ICMP standard for IPv4 and IPv6, and does not change. The protocols are free to utilize the Code for their own purposes. The ICMP Experimental Mobility Type defines a one octet subtype field within the ICMP Reserved field that identifies the specific protocol. The ICMP header for the Experimental Mobility Type is:
ICMP実験機動型は、次のようにカードとCXTPによって利用されています。 Codeフィールドの解釈は、IPv4とIPv6に関連するICMP標準によって定義されているようであり、変更されません。プロトコルは、独自の目的のためにコードを利用するのは自由です。 ICMP実験モビリティタイプは、特定のプロトコルを識別するICMP Reservedフィールド内の1つのオクテットサブタイプフィールドを定義します。実験機動型のためのICMPヘッダは次のとおりです。
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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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 For IPv4, 41; for IPv6 150
IPv4の、41の型。 IPv6の150用
Code As defined by the relevant ICMP specification and free for use by the Experimental Mobility protocol.
関連するICMP仕様で定義されており、実験モビリティプロトコルで使用するための無料のようなコード。
Checksum ICMP checksum
チェックサムICMPチェックサム
Subtype One octet subtype code identifying the Experimental Mobility protocol
実験モビリティプロトコルを識別するサブタイプ1つのオクテットのサブタイプコード
Reserved Unless otherwise defined by the Experimental Mobility protocol, set to zero by the sender and ignored by the receiver.
それ以外の場合は実験モビリティプロトコルによって定義されない限り予約、送信者によってゼロに設定し、受信側では無視されます。
Options As defined by the Experimental Mobility protocol.
実験モビリティプロトコルで定義されているようにオプション。
IANA SHALL maintain a registry of one octet unsigned integer subtype codes for the Experimental Mobility protocols called the Experimental Mobility Protocol Subtype Registry.
IANAは、実験的なモビリティプロトコルサブタイプレジストリと呼ばれる実験的なモビリティプロトコルの1つのオクテットの符号なし整数のサブタイプコードのレジストリを維持しなければなりません。
Initial allocations in the registry SHALL be established as follows:
次のようにレジストリ内の初期配分が確立されなければなりません。
Protocol/Message Subtype Reference
----------------------------------------------------------
CARD 0 Section 5.1.1 of [RFC4066]
CXTP 1 Section 3.2 of [RFC4067]
Subsequent allocations of subtype codes SHALL be made by the method of Specification Required and IESG Review as defined in RFC 2434.
RFC 2434で定義されているサブタイプコードの割り振りは、仕様が必要とIESGレビューの方法によらなければなりません。
The ICMP Experimental Mobility type code is available for other experimental mobility protocols to use. Other experimental mobility protocols MAY define additional ICMP messages that use code points under the Experimental Mobility ICMP type.
他の実験モビリティプロトコルを使用するためにICMP実験的なモビリティのタイプコードが入手可能です。他の実験モビリティプロトコルは、実験的なモビリティICMPタイプの下のコード・ポイントを使用して、追加のICMPメッセージを定義することができます。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC4066] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005.
[RFC4066] Liebsch、M.、編、シン、A.編、Chaskar、H.、船戸、D.、およびE.シム、 "候補アクセスルータ発見（CARD）"、RFC 4066、2005年7月。
[RFC4067] Loughney, J., Ed., Nahkjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol", RFC 4067, July 2005.
[RFC4067] Loughney、J.、編、Nahkjiri、M.、パーキンス、C.、およびR. Koodli、 "コンテキスト転送プロトコル"、RFC 4067、2005年7月。
There are no security considerations associated with this document.
この文書に関連付けられたセキュリティ上の考慮事項はありません。
This entire document is about IANA considerations.
この文書全体ではIANA問題についてです。
Author's Address
著者のアドレス
James Kempf DoCoMo Labs USA 181 Metro Drive Suite 300 San Jose, CA 95110
ジェームズ・ケンプドコモ研究所USA 181メトロドライブスイート300サンノゼ、CA 95110
Phone: +1 408 451 4711 EMail: kempf@docomolabs-usa.com
電話：+1 408 451 4711 Eメール：kempf@docomolabs-usa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。