Network Working Group G. Dommety
Request for Comments: 3025 K. Leung
Category: Standards Track cisco Systems
February 2001
Network Working Group G. Dommety
Request for Comments: 3025 K. Leung
Category: Standards Track cisco Systems
February 2001
Mobile IP Vendor/Organization-Specific Extensions
移动IP供应商/组织特定扩展
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 Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes.
本文档定义了移动IP的两个新扩展。这些扩展将有助于设备供应商和组织在其认为适合用于研究或部署目的时具体使用这些扩展。
Current specification of Mobile IP [1] does not allow for organizations and vendors to include organization/vendor-specific information in the Mobile IP messages. With the imminent wide scale deployment of Mobile IP it is useful to have vendor or organization-Specific Extensions to support this capability. This document defines two extensions that can be used for making organization specific extensions by vendors/organizations for their own specific purposes.
当前的移动IP规范[1]不允许组织和供应商在移动IP消息中包含特定于组织/供应商的信息。随着移动IP即将大规模部署，拥有特定于供应商或组织的扩展来支持此功能非常有用。本文档定义了两个扩展，可用于供应商/组织为其特定目的进行特定于组织的扩展。
The keywords "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 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。
In addition, the following words are used to signify the requirements of the specification.
此外，以下词语用于表示本规范的要求。
silently discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter.
静默放弃实现放弃数据报，无需进一步处理，也无需向发送方指示错误。实现应提供记录错误的能力，包括丢弃数据报的内容，并应在统计计数器中记录事件。
Two Vendor/Organization Specific Extensions are described, Critical (CVSE) and Normal (NVSE) Vendor/Organization Specific Extensions. The basic differences between the Critical and Normal Extensions are that when the Critical extension is encountered but not recognized, the message containing the extension MUST be silently discarded, whereas when a Normal Vendor/Organization Specific Extension is encountered but not recognized, the extension SHOULD be ignored, but the rest of the Extensions and message data MUST still be processed. Another difference between the two is that Critical Vendor/Organization Extension has a length field of two octets and the NVSE has a length field of only one octet.
描述了两个特定于供应商/组织的扩展：关键（CVSE）和正常（NVSE）特定于供应商/组织的扩展。关键扩展和普通扩展之间的基本区别在于，当遇到关键扩展但无法识别时，包含该扩展的消息必须以静默方式丢弃，而当遇到正常供应商/组织特定扩展但无法识别时，应忽略该扩展，但其余的扩展和消息数据仍必须处理。两者之间的另一个区别是，关键供应商/组织扩展的长度字段为两个八位字节，而NVSE的长度字段仅为一个八位字节。
The format of this extension is as shown below.
此扩展的格式如下所示。
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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-CVSE-Type | Vendor-CVSE-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-CVSE-Type | Vendor-CVSE-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Critical Vendor/Organization Specific Extension
图1：关键供应商/组织特定扩展
Type CVSE-TYPE-NUMBER 37
类型CVSE-类型编号37
Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception.
保留以备将来使用。发送时必须设置为0，接收时必须忽略。
Length Length in bytes of this extension, not including the Type and Length bytes.
此扩展的长度（字节），不包括类型和长度字节。
Vendor/Org-ID The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [2].
供应商/组织ID高阶八位字节为0，低阶三位字节为供应商的SMI网络管理专用企业代码，按网络字节顺序排列，如分配编号RFC[2]中所定义。
Vendor-CVSE-Type Indicates the particular type of Vendor-CVSE-Extension. The administration of the Vendor-CVSE-Types is done by the Vendor.
供应商CVSE类型表示供应商CVSE扩展的特定类型。供应商CVSE类型的管理由供应商完成。
Vendor-CVSE-Value Vendor/organization specific data of this Vendor-CVSE-Extension. These data fields may be published in future RFCs. The Vendor-CVSE-Value is zero or more octets. The length of this field can be computed from the Length Field Value.
供应商CVSE值此供应商CVSE扩展的供应商/组织特定数据。这些数据字段可能会在未来的RFC中发布。供应商CVSE值为零或多个八位字节。此字段的长度可以根据长度字段值计算。
If an implementation does not recognize the CVSE, according to RFC 2002 [1], the entire packet is to be silently dropped.
如果实现不识别CVSE，根据RFC 2002[1]，整个数据包将被静默丢弃。
The format of this extension is as shown below.
此扩展的格式如下所示。
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-NVSE-Type | Vendor-NVSE-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-NVSE-Type | Vendor-NVSE-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Normal Vendor/Organization Specific Extension
图2：正常的供应商/组织特定扩展
Type NVSE-TYPE-NUMBER 133
型号NVSE-Type-NUMBER 133
Length Length in bytes of this extension, not including the Type and Length bytes.
此扩展的长度（字节），不包括类型和长度字节。
Reserved Reserved for future use. To be set to 0.
保留以备将来使用。设置为0。
Vendor/Org-ID The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [2].
供应商/组织ID高阶八位字节为0，低阶三位字节为供应商的SMI网络管理专用企业代码，按网络字节顺序排列，如分配编号RFC[2]中所定义。
Vendor-NVSE-Type Indicates the particular type of Vendor-NVSE-Extension. The administration of the Vendor-NVSE-Types is done by the Vendor.
供应商NVSE类型表示供应商NVSE扩展的特定类型。供应商NVSE类型的管理由供应商完成。
Vendor-NVSE-Value Vendor/organization specific data of this Vendor-NVSE-Extension. These data fields may be published in future RFCs. The Vendor-NVSE-Value is zero or more octets. The length of this field can be computed from the Length Field Value.
供应商NVSE值此供应商NVSE扩展的供应商/组织特定数据。这些数据字段可能会在未来的RFC中发布。供应商NVSE值为零或多个八位字节。此字段的长度可以根据长度字段值计算。
When a Mobile IP entity receives a registration request message (or any other request/update message) with an extension of type CVSE-TYPE-NUMBER and recognizes it, but the extension contains an unknown/unsupported vendor ID or Vendor-CVSE-Type, a registration reject (or the appropriate deny message) MUST be sent with the error code to indicate that the registration was rejected due to the presence of an unknown CVSE.
当移动IP实体接收到带有CVSE-type-NUMBER类型扩展名的注册请求消息（或任何其他请求/更新消息）并识别该消息，但该扩展名包含未知/不受支持的供应商ID或供应商CVSE类型时，注册拒绝（或相应的拒绝消息）必须与错误代码一起发送，以指示由于存在未知CVSE而拒绝注册。
When a Mobile IP entity receives a registration reply (or any other mobile IP reply/acknowledgement message) with an extension of type CVSE-TYPE-NUMBER and recognizes it, but the extensions contains an unknown/unsupported vendor ID or Vendor-CVSE-Type, the processing is performed as described below.
当移动IP实体接收到带有CVSE-type-NUMBER类型扩展名的注册回复（或任何其他移动IP回复/确认消息）并识别它时，但扩展名包含未知/不受支持的供应商ID或供应商CVSE类型，处理如下所述。
1. If the Mobile IP entity is a transit node for the reply (i.e., this entity processes and sends the registration reply to another entity) a registration reject (or the appropriate deny message) MUST be sent with the error code to indicate that the registration was rejected due to the presence of an unknown CVSE. For example, FA when it receives an unknown CVSE in a registration reply from the HA, should send a registration reject to the MN.
1. 如果移动IP实体是应答的中转节点（即，该实体处理注册应答并将其发送给另一实体），则必须发送注册拒绝（或相应的拒绝消息）以及错误代码，以指示由于存在未知CVSE而拒绝注册。例如，FA在收到来自HA的注册回复中的未知CVSE时，应向MN发送注册拒绝。
2. If the Mobile IP entity is not a transit node for the reply, the reply is treated as a reject (or the appropriate deny message) due to the presence of an unknown CVSE.
2. 如果移动IP实体不是应答的中转节点，则由于未知CVSE的存在，应答被视为拒绝（或适当的拒绝消息）。
While designing enhancements wherein a CVSE is included in a reply message, it should noted that the reply message could be discarded by the mobile IP entity processing this message. Enhancements that include a CVSE should take this into consideration during design.
在设计其中CVSE包括在回复消息中的增强时，应当注意，处理该消息的移动IP实体可以丢弃该回复消息。包括CVSE的增强功能应在设计过程中考虑到这一点。
When a Mobile IP entity receives a mobile IP related message (registration request/reply, advertisement/solicitation, etc.) with an extension of type NVSE-TYPE-NUMBER and recognizes it, but the extension contains an unknown/unsupported vendor ID or Vendor-NVSE-Type, the entire extension is skipped.
当移动IP实体接收到扩展名为NVSE-type-NUMBER的移动IP相关消息（注册请求/回复、广告/请求等）并识别该消息，但该扩展名包含未知/不受支持的供应商ID或供应商NVSE类型时，将跳过整个扩展名。
NOTE that according to RFC 2002 [1], when an extension numbered within the range 0 through 127 is encountered in a registration message but not recognized, the message containing that extension MUST be silently discarded. This document is compliant with the above specification and specifies the action if the extension of type CVSE-TYPE-NUMBER is encountered and recognized, but does not support the vendor ID or the vendor type extension within.
请注意，根据RFC 2002[1]，当在注册消息中遇到编号在0到127范围内的扩展但未被识别时，必须以静默方式丢弃包含该扩展的消息。本文件符合上述规范，并规定了在遇到和识别CVSE-type-NUMBER类型扩展时的操作，但不支持供应商ID或内部的供应商类型扩展。
The following error codes are defined.
定义了以下错误代码。
Registration denied by the Foreign agent:
外国代理拒绝注册：
ERROR-FA-1 100: Unsupported Vendor-ID or unable to interpret Vendor-CVSE-Type in the CVSE sent by the Mobile Node to the Foreign Agent.
错误-FA-1 100:不支持供应商ID或无法解释移动节点发送给外部代理的CVSE中的供应商CVSE类型。
ERROR-FA-2 101: Unsupported Vendor-ID or unable to interpret Vendor-CVSE-Type in the CVSE sent by the Home Agent to the Foreign Agent.
错误-FA-2 101:不支持供应商ID或无法解释本地代理发送给外部代理的CVSE中的供应商CVSE类型。
Registration denied by the Home agent:
注册被总部代理拒绝：
ERROR-HA-1 140: Unsupported Vendor-ID or unable to interpret Vendor-CVSE-Type in the CVSE sent by the Mobile Node to the Home Agent.
ERROR-HA-1 140:不支持供应商ID或无法解释移动节点发送给归属代理的CVSE中的供应商CVSE类型。
ERROR-HA-2 141: Unsupported Vendor-ID or unable to interpret Vendor-CVSE-Type in the CVSE sent by the Foreign Agent to the Home Agent.
错误-HA-2 141:不支持供应商ID或无法解释外部代理发送给本地代理的CVSE中的供应商CVSE类型。
Multiple TLV's with the types CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER can be included in a message. TLVs with types CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER can be placed anywhere after the fixed portion of the Mobile IP message. These TLVs are expected to be protected by the corresponding authenticator as necessary. Ordering of these TLV's should not be modified by intermediate nodes.
消息中可以包含多个类型为CVSE-TYPE-NUMBER和NVSE-TYPE-NUMBER的TLV。CVSE-TYPE-NUMBER和NVSE-TYPE-NUMBER类型的TLV可以放置在移动IP消息固定部分之后的任何位置。如有必要，这些TLV将受到相应验证器的保护。中间节点不应修改这些TLV的顺序。
The Critical Vendor/Organization Specific Extension (CVSE) as defined in Section 2.1 and Normal Vendor/Organization Specific Extension (NVSE) as defined in section 2.2 are proposed new extensions to the Mobile IP protocol, defined in RFC 2002 [1] and extended in RFC 2356 [5].
第2.1节中定义的关键供应商/组织特定扩展（CVSE）和第2.2节中定义的正常供应商/组织特定扩展（NVSE）是移动IP协议的拟议新扩展，在RFC 2002[1]中定义，并在RFC 2356[5]中扩展。
IANA has assigned a Type value of CVSE-TYPE-NUMBER for the Critical Vendor/Organization Specific Extension (CVSE), and a Type value of NVSE-TYPE-NUMBER for the Normal Vendor/Organization Specific Extension (NVSE). The numbers CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER for the CVSE and the NVSE are taken from the numbering space defined for Mobile IP registration extensions [1].
IANA为关键供应商/组织特定扩展（CVSE）分配了CVSE-Type-NUMBER类型值，为正常供应商/组织特定扩展（NVSE）分配了NVSE-Type-NUMBER类型值。CVSE和NVSE的编号CVSE-TYPE-NUMBER和NVSE-TYPE-NUMBER取自为移动IP注册扩展定义的编号空间[1]。
IANA has assigned new Foreign Agent Error Codes, ERROR-FA-1 and ERROR-FA-2 taken from the numbering space defined for Mobile IP Foreign Agent error codes [1]. IANA has also assigned new Home Agent Error Codes, ERROR-HA-1 and ERROR-HA-2 taken from the numbering space defined for Mobile IP Home Agent error codes [1].
IANA已分配了新的外部代理错误代码，Error-FA-1和Error-FA-2取自为移动IP外部代理错误代码定义的编号空间[1]。IANA还分配了新的归属代理错误代码，Error-HA-1和Error-HA-2取自为移动IP归属代理错误代码定义的编号空间[1]。
This document assumes that the Mobile IP messages are authenticated using a method defined by the Mobile IP protocol. This document does not impose any additional requirements on Mobile IP messages from a security point of view. So this is not expected to be a security issue.
本文档假设使用移动IP协议定义的方法对移动IP消息进行身份验证。从安全角度来看，本文件不对移动IP消息提出任何附加要求。因此，这不是一个安全问题。
The authors would like to thank TR45.4 WG, TR45.6 WG, Basavaraj Patil, Phil Roberts, Jouni Malinen, and Patrice Calhoun for their useful discussions.
作者要感谢TR45.4工作组、TR45.6工作组、Basavaraj Patil、Phil Roberts、Jouni Malinen和Patrice Calhoun的有益讨论。
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[1] Perkins，C.，“IP移动支持”，RFC 2002，1996年10月。
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[2] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998.
[4] 黑山G.“移动IP的反向隧道”，RFC 2344，1998年5月。
[5] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[5] 黑山，G.和V.Gupta，“Sun的移动IP跳过防火墙穿越”，RFC 2356，1998年6月。
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Gopal Dommety Cisco Systems，Inc.加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: gdommety@cisco.com
EMail: gdommety@cisco.com
Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Kent Leung Cisco Systems，Inc.加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: kleung@cisco.com
EMail: kleung@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。