Network Working Group V. Devarapalli
Request for Comments: 5094 Azaire Networks
Category: Standards Track A. Patel
K. Leung
Cisco
December 2007
Network Working Group V. Devarapalli
Request for Comments: 5094 Azaire Networks
Category: Standards Track A. Patel
K. Leung
Cisco
December 2007
Mobile IPv6 Vendor Specific Option
移动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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
There is a need for vendor-specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor-specific mobility option.
需要对移动报头消息进行特定于供应商的扩展，以便移动IPv6供应商能够出于研究或部署目的扩展协议。本文件定义了一个新的供应商专用移动选项。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Vendor-Specific Mobility Option . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Vendor-Specific Mobility Option . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Vendor-specific messages have traditionally allowed vendors to implement extensions to some protocols and distinguish themselves from other vendors. These messages are clearly marked by a Vendor ID that identifies the vendor. A particular vendor's implementation identifies the vendor extension by recognizing the Vendor ID. Implementations that do not recognize the Vendor ID either discard or skip processing the message.
特定于供应商的消息传统上允许供应商实现对某些协议的扩展，并将自己与其他供应商区分开来。这些消息由标识供应商的供应商ID明确标记。特定供应商的实现通过识别供应商ID来标识供应商扩展。不识别供应商ID的实现放弃或跳过处理消息。
Mobile IPv6 [2] is being deployed and there is a need for vendor-specific extensions to Mobility Header messages so that vendors are able to extend the Mobile IPv6 protocol for research or deployment purposes.
移动IPv6[2]正在部署中，需要对移动报头消息进行特定于供应商的扩展，以便供应商能够出于研究或部署目的扩展移动IPv6协议。
This document defines a new mobility option, the Vendor-Specific Mobility Option, which can be carried in any Mobility Header message. The Vendor-Specific mobility option MUST be used only with a 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 NEMO [3] and Proxy MIPv6 [4] since these protocols also use Mobility Header messages.
本文档中定义的消息也可用于NEMO[3]和代理MIPv6[4]，因为这些协议也使用移动报头消息。
Vendor-specific protocol extensions can cause serious interoperability issues and may in addition have adverse operational impact, if they are not designed and used carefully. The vendor-specific option described in this document is meant to support simple use cases where it is sufficient to include some vendor data in the standardized Mobile IPv6 protocol exchanges. The vendor-specific option is not suitable for more complex vendor extensions that modify Mobile IPv6 itself. Although these options allow vendors to piggyback additional data onto Mobile IPv6 message exchanges, RFC 3775 [2] requires that unrecognized options be ignored and that the end systems be able to process the remaining parts of the message correctly. Extensions that use the vendor-specific mobility option should require an indication that the option was processed, in the response, using the vendor-specific mobility option.
供应商特定的协议扩展可能会导致严重的互操作性问题，此外，如果没有仔细设计和使用，还可能产生不利的操作影响。本文档中描述的特定于供应商的选项旨在支持简单的用例，在这些用例中，在标准化的移动IPv6协议交换中包含一些供应商数据就足够了。特定于供应商的选项不适用于修改移动IPv6本身的更复杂的供应商扩展。尽管这些选项允许供应商将附加数据装载到移动IPv6消息交换上，但RFC 3775[2]要求忽略未识别的选项，并且终端系统能够正确处理消息的其余部分。使用特定于供应商的移动性选项的扩展应要求在响应中指示该选项是使用特定于供应商的移动性选项处理的。
Vendors are generally encouraged to bring their protocol extensions to the IETF for review and standardization. Complex vendor extensions that modify Mobile IPv6 itself, will see large-scale deployment or involve industry consortia, or other multi-vendor organizations MUST be standardized in the IETF. Past experience has shown that such extensions of IETF protocols are critically dependent on IETF review and standardization.
通常鼓励供应商将其协议扩展带到IETF进行审查和标准化。修改移动IPv6本身的复杂供应商扩展，将看到大规模部署或涉及行业联盟，或其他多供应商组织必须在IETF中标准化。过去的经验表明，IETF协议的这种扩展严重依赖于IETF审查和标准化。
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 Vendor Specific Mobility Option can be included in any Mobility Header message and has an alignment requirement of 4n+2. If the Mobility Header message includes a Binding Authorization Data option [2], then the Vendor Specific mobility option should appear before the Binding Authorization Data option. Multiple Vendor-Specific mobility options MAY be present in a Mobility Header message.
特定于供应商的移动性选项可以包含在任何移动性标头消息中，并且具有4n+2的对齐要求。如果移动头消息包含绑定授权数据选项[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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Data.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
An 8-bit field indicating that it is a Vendor-Specific mobility option.
一个8位字段，指示它是供应商特定的移动选项。
Length
长
An 8-bit field indicating the length of the option in octets excluding the Type and the Length fields. All other fields are included.
一个8位字段，以八位字节表示选项的长度，不包括类型和长度字段。包括所有其他字段。
Vendor ID
供应商ID
The SMI Network Management Private Enterprise Code of the IANA-maintained Private Enterprise Numbers registry [5].
IANA的SMI网络管理私有企业代码维护私有企业编号注册[5]。
Sub-type
子类型
An 8-bit field indicating the type of vendor-specific information carried in the option. The administration of the Sub-type is done by the Vendor.
一个8位字段，指示选项中包含的供应商特定信息的类型。子类型的管理由供应商完成。
Data
数据
Vendor-specific data that is carried in this message.
此消息中包含的供应商特定数据。
The Vendor-Specific mobility messages should be protected in a manner similar to Binding Updates and Binding Acknowledgements if it carries 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. In particular, the messages containing the Vendor Specific mobility option MUST be integrity protected.
如果特定于供应商的移动消息包含不应在线路上显示的信息或可能影响归属代理或对应节点处的绑定缓存条目的信息，则应以类似于绑定更新和绑定确认的方式对其进行保护。特别是，包含特定于供应商的移动选项的消息必须受到完整性保护。
The Vendor-Specific mobility option, defined in Section 3, has been assigned the type value (19), allocated from the same space as the Mobility Options registry created by RFC 3775 [2].
第3节中定义的特定于供应商的移动选项已分配类型值（19），该值从RFC 3775[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] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[3] Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[4] Gundavelli, S., "Proxy Mobile IPv6", Work in Progress, March 2007.
[4] Gundavelli，S.，“代理移动IPv6”，正在进行的工作，2007年3月。
[5] IANA Assigned Numbers Online Database, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers>.
[5] IANA分配编号在线数据库，“私营企业编号”<http://www.iana.org/assignments/enterprise-numbers>.
Authors' Addresses
作者地址
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA
Vijay Devarapalli Azaire Networks美国加利福尼亚州圣克拉拉市杰街3121号，邮编95054
EMail: vijay.devarapalli@azairenet.com
EMail: vijay.devarapalli@azairenet.com
Alpesh Patel Cisco 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: alpesh@cisco.com
EMail: alpesh@cisco.com
Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: kleung@cisco.com
EMail: kleung@cisco.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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。