Network Working Group G. Dommety Request for Comments: 3115 K. Leung Obsoletes: 3025 cisco Systems Category: Standards Track April 2001 Mobile IP Vendor/Organization-Specific Extensions 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. RFC Editor Note: This memo corrects discrepancies between the values assigned for CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER in RFC 3025 and in the Internet Assigned Numbers Authority's (IANA) repository. The difference in the assigned values are as follows: CVSE-TYPE-NUMBER = 37 in RFC 3025 CVSE-TYPE-NUMBER = 38 in IANA (Under Mobile IP numbers) NVSE-TYPE-NUMBER = 133 in RFC 3025 NVSE-TYPE-NUMBER = 134 in IANA (Under Mobile IP numbers) This memo obsoletes RFC 3025, since the current implementations follow the IANA assignments.
AbstractThis 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.
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. RFC 2119 . 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.
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 Type CVSE-TYPE-NUMBER 38 Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception. 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 . Vendor-CVSE-Type Indicates the particular type of Vendor-CVSE-Extension. The administration of the Vendor-CVSE-Types is done by the Vendor. 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. If an implementation does not recognize the CVSE, according to RFC 2002 , the entire packet is to be silently dropped.
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 Type NVSE-TYPE-NUMBER 134 Length Length in bytes of this extension, not including the Type and Length bytes. Reserved Reserved for future use. To be set to 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 . Vendor-NVSE-Type Indicates the particular type of Vendor-NVSE- Extension. The administration of the Vendor-NVSE-Types is done by the Vendor. 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.
RFC 2002 , 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.
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  and extended in RFC 2356 . 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 .
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 . 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 .  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998.  Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.