Network Working Group J. Kempf
Request for Comments: 4065 DoCoMo Labs USA
Category: Experimental July 2005
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).
版权所有（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切换的实验协议。这些协议需要IANA分配ICMP类型和选项、流控制传输协议（SCTP）有效负载协议标识符、端口号以及某些格式化消息选项的注册表。本文件包含对IANA的说明，说明Seamoby协议需要哪些分配。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
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，并为某些格式化消息选项建立注册表。因为这些协议是实验性的，所以不能保证它们会以当前的形式得到广泛的部署。因此，谨慎的做法是保存其他协议可能需要的Internet编号资源，这些协议可能会得到更广泛的部署。本文件包含IANA关于Seamoby协议的说明。此外，还设计了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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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已分配SCTP端口号5090供[RFC4066]使用，5091供[RFC4067]使用。请参见[RFC4066]第5.2.1节了解SCTP的接入路由器卡协议使用说明，以及[RFC4067]第3.1节了解SCTP的接入路由器CXTP使用说明。
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分配了ICMP类型41，用于识别实验性移动协议（如Seamoby）使用的ICMP消息。关于Seamoby指定的实验性移动卡ICMP消息的说明，请参见[RFC4066]第5.1.1节；关于CXTP ICMP消息，请参见[RFC4067]第3.2节。有关实验移动协议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]
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分配了ICMP类型代码150，用于识别实验性移动协议（如Seamoby）使用的ICMP消息。关于Seamoby指定的实验性移动卡ICMP消息的说明，请参见[RFC4066]第5.1.1节；关于CXTP ICMP消息，请参见[RFC4067]第3.2节。有关实验移动协议子类型格式和初始分配的说明，请参见本文档第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]
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:
对于CARD，将创建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类型空间，以包括新的AVP。AVP类型代码是16位无符号整数。有关AVP的说明，请参见[RFC4066]第5.1.4节。
The registry SHALL be initially populated with the following table:
注册表应首先填写下表：
AVP Name Type Code
----------------------------------------------
RESERVED 0x00
AVP Name Type Code
----------------------------------------------
RESERVED 0x00
Future allocations of AVP type codes will be made through Expert Review, as defined in RFC 2434.
AVP类型代码的未来分配将通过RFC 2434中定义的专家评审进行。
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 type字段中唯一标识特定的访问技术。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
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位无符号整数，用于标识要素上下文的特定类型。参见[RFC4067]第2.4节，了解如何在CXTP中承载上下文。
The registry SHALL initially be populated with the following table:
注册表最初应填写下表：
Context Profile Type Code
----------------------------------------------
RESERVED 0x00
IPv6 Multicast Listener Context 0x01
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实验移动性类型由CARD和CXTP按以下方式使用。代码字段的解释由IPv4和IPv6的相关ICMP标准定义，并且不会更改。协议可以自由地将代码用于自己的目的。ICMP实验移动性类型在ICMP保留字段中定义一个八位组子类型字段，用于标识特定协议。实验移动性类型的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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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
子类型识别实验移动协议的一个八位组子类型代码
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应为实验移动协议维护一个八位组无符号整数子类型代码的注册表，称为实验移动协议子类型注册表。
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]
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）的邻居发现”，RFC2461，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，“上下文传输协议”，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
詹姆斯·肯普夫·多科莫实验室美国加利福尼亚州圣何塞市地铁大道181号套房300号，邮编95110
Phone: +1 408 451 4711
EMail: kempf@docomolabs-usa.com
Phone: +1 408 451 4711
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。