[要約] RFC 4065は、Seamobyと実験的なモビリティプロトコルのIANA割り当てに関する指示を提供しています。このRFCの目的は、これらのプロトコルの割り当てに関する一貫性と正確性を確保することです。
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
Seamobyおよび実験的モビリティプロトコルIANAの割り当ての指示
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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候補アクセスルーター発見（カード）プロトコルとコンテキスト転送プロトコル（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オプションのIANA割り当てとタイプ、SCTPペイロードプロトコル識別子、ポート番号、および特定のフォーマットされたメッセージオプションのレジストリの確立が必要です。プロトコルは実験的であるため、現在の形式で広範囲に展開されるという保証はありません。その結果、より広い展開を見ることができる他のプロトコルに必要な可能性のあるインターネット番号のリソースを節約することは賢明です。このドキュメントには、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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は、[RFC4066]および[RFC4067]を使用するために使用するためにSCTPポート番号5090を割り当てました。SCTPのアクセス間ルーターカードプロトコルの使用の説明については、[RFC4066]のセクション5.2.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は、Seamobyなどの実験的モビリティプロトコルによって使用されるICMPメッセージを識別するIPv4にICMPタイプ41を割り当てました。Seamobyが指定したCXTP ICMPメッセージの実験的モビリティカードの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は、Seamobyなどの実験的モビリティプロトコルによって使用されるICMPメッセージを識別するIPv6にICMPタイプコード150を割り当てています。Seamobyが指定したCXTP ICMPメッセージの実験的モビリティカードの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 Neighbor Discovery [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:
カードの場合、IANAが維持する2つの新しいレジストリが作成されます。
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タイプスペースの将来の拡張が可能になり、新しい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.
Layer 2 Access Technology Identifier Registryを使用すると、タイプコードの登録を使用して、カードL2 IDサブオプションのL2型フィールドにある特定のアクセステクノロジーを一意に識別できます。L2 IDコードは、16ビット署名されていない整数です。カード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によって使用されます。コードフィールドの解釈は、IPv4およびIPv6の関連するICMP標準によって定義されているとおりであり、変更されません。プロトコルは、独自の目的でコードを自由に利用できます。ICMP実験モビリティタイプは、特定のプロトコルを識別するICMP予約フィールド内の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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type For IPv4, 41; for IPv6 150 Code As defined by the relevant ICMP specification and free for use by the Experimental Mobility protocol.
IPv4、41のタイプ。関連するICMP仕様で定義されたIPv6 150コードの場合、実験的モビリティプロトコルで使用するための無料。
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つのOctet Unseded Integerサブタイプコードのレジストリを維持するものとします。
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. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、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.、Ed。、Singh、A.、Ed。、Chaskar、H.、Funato、D。、およびE. Shim、「候補アクセスルーター発見（カード）」、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.、Ed。、Nahkjiri、M.、Perkins、C。、およびR. Koodli、「Context Transfer Protocol」、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
James Kempf Docomo Labs USA 181 Metro Drive Suite 300 San Jose、CA 95110
Phone: +1 408 451 4711
EMail: kempf@docomolabs-usa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。