Network Working Group V. Devarapalli
Request for Comments: 5096 Azaire Networks
Category: Standards Track December 2007
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
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].
在试验协议或定义协议的新扩展时，需要协议编号、新消息或携带与试验相关信息的选项。大多数实现最终都会对新消息使用未分配的值。很多时候，如果IANA通过IETF标准行动分配相同的值，或者如果实现与这些消息一起部署，则会产生问题。因此，为实验目的留出一些代码点来标识实验协议或消息被认为是一种良好的做法。[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.
本文档定义了一个新的移动头消息，它是可由移动节点、归属代理或对应节点随时发送的实验性移动消息。由于移动报头消息不能在一个数据包中组合和发送，因此在任何移动IPv6数据包中始终只有一个移动报头消息。不识别移动消息类型的归属代理或对应节点实现，丢弃消息并发送绑定错误消息，如[2]中所述，状态字段设置为2（未识别的MH类型值）。不识别移动消息类型的移动节点应丢弃该消息并发送ICMP参数问题，代码为0。
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.
实验机制只能用于实际实验。根据设计，只为消息分配一个代码点，为选项分配另一个代码点。这将一组对等点之间的实验数量限制为一次一个。当实验机制被证明是有用的，并且希望在实验之外部署它们时，应该对它们进行标准化并给出新的代码点。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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节中定义的移动报头消息。除了Mobility标头中的必填字段外，消息中没有其他字段。移动性报头中的“MH Type”字段表示它是一条实验性移动性报头消息。
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.
如果消息中没有数据，则需要两个字节的填充。由于在计算移动报头消息的长度时排除了前8个八位字节，因此移动报头中的“报头长度”字段设置为0。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
请参阅RFC 3775[2]，了解“有效负载协议”、“标题Len”、“MH类型”、“保留”和“校验和”字段的说明。
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 .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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节中定义的实验性移动性报头消息已被分配类型值（11），该值从与移动性报头中的“MH type”字段相同的空间分配[2]。
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 37752004年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，“网络移动（NEMO）基本支持协议”，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大美洲圣克拉拉Pkwy，加利福尼亚州，美国95054
EMail: vijay.devarapalli@azairenet.com
EMail: vijay.devarapalli@azairenet.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从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.