Mobile IP Working Group Gopal Dommety INTERNET DRAFT Kent Leung November 1999 Cisco Systems Expires May 2000 Mobile IP Vendor/Organization-Specific Extensions draft-ietf-mobileip-vendor-ext-07.txt Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes two new extensions to Mobile IP [1]. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. Dommety, Leung [Page 1] Internet Draft Mobile IP Vendor-Specific Extensions November 1999 1. Introduction 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 draft proposes two extensions that can be used for making organization specific extensions by vendors/organizations for their own specific purposes. 1.1. Specification Language 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 [8]. 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. 2. Vendor/Organization Specific Extensions 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. 2.1. Critical Vendor/Organization Specific Extension (CVSE) 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-Type | Opaque Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Critical Vendor/Organization Specific Extension Type 38 (not skippable) (see [1]) 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 Dommety, Leung [Page 2] Internet Draft Mobile IP Vendor-Specific Extensions November 1999 are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [2]. Vendor-Type Indicates the particular type of Extension. The administration of the Vendor-Types is done by the Vendor. Opaque Data Vendor/organization specific data. These data fields may be published in future RFCs. The opaque data is zero or more octets. The actual format of the opaque data is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. It is recommended that opaque data be encoded as a sequence of vendor length/value fields. The length field of this extension is chosen to be two bytes long to allow for more than 248 bytes of Opaque Data. If an implementation does not recognize the CVSE, according to RFC [1] the entire packet is to be silently dropped. But if an agent recognizes the CVSE, then it is aware of how to deal with the length size. 2.2. Normal Vendor/Organization Specific Extension (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 | Length | Reserved | Vendor/Org-ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor/Org-ID (cont) | Vendor-Type +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vend-Type(cont)| Opaque Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Normal Vendor/Organization Specific Extension Type 134 (skippable) (see [1]) 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 [2]. Vendor-Type Indicates the particular type of Extension. Opaque Data Vendor/organization specific data. These data fields may be publicized in future RFCs. The opaque data is zero or more octets. 2.3 Vendor/Organization Specific Extensions Processing Considerations When a Mobile IP entity receives a registration request message (or any other request/update message) with an extension of type 38 (CVSE) and recognizes it, but the extension contains an unknown/unsupported vendor ID or does not know how to interpret the opaque data or a part of opaque data, 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. When a Mobile IP entity receives a registration reply (or any other mobile IP reply/acknowledement message) with an extension of type 38 (CVSE) and recognizes it, but the extensions contains an unknown/unsupported vendor ID or does not know how to interpret the opaque data or a part of opaque data, the packet is silently discarded. When a Mobile IP entity receives a mobile IP realted message (registration request/reply, advertisement/solicitation, etc) with an extension of type 134 (NVSE) and recognizes it, but the extension contains an unknown/unsupported vendor ID or does not know how to interpret the opaque data or a part of opaque data, that particular extension is skipped. NOTE that according to RFC [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 draft is compliant with the above specification and specifies the action if the extension of type 38 is encountered and recognized, but does not support the vendor ID or the vendor type extension within. 2.4 Error Codes The following error codes are defined. Registration denied by the Foreign agent: 107: Unsupported Vendor-ID or unable to interpret Opaque Data in the CVSE sent by the Mobile Node to the Foreign Agent. 108: Unsupported Vendor-ID or unable to interpret Opaque Data in the CVSE sent by the Home Agent to the Foreign Agent. Registration denied by the Home agent: 141: Unsupported Vendor-ID or unable to interpret Opaque Data in the CVSE sent by the Mobile Node to the Home Agent. 142: Unsupported Vendor-ID or unable to interpret Opaque Data in the CVSE sent by the Foreign Agent to the Home Agent. Dommety, Leung [Page 3] Internet Draft Mobile IP Vendor-Specific Extensions November 1999 3. Restrictions Multiple TLV's with the types 38 and 134 can be included in a message. TLVs with types 38 and 134 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. 4. IANA Considerations The numbers for the Vendor/Organization Specific extensions are taken from the numbering space defined for Mobile IP registration extensions defined in RFC 2002 [1]. The number for CVSE (section 2.2) is taken from the range 0-127 (not skippable) and the number for NVSE (section 2.3) is taken from the range 128-255 (skippable). These MUST NOT conflict with any numbers used in RFC 2002[1], RFC 2344 [3], RFC 2356 [4], Mobile IP Challenge/Response Extensions Draft [5], Mobile IP Network Access Identifier Extensions Draft[6], or Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network Draft [7]. The Code values specified for errors, listed in section 2.5, MUST NOT conflict with any other code values listed in RFC 2002[1], RFC 2344 [3], RFC 2356 [4] Mobile IP Challenge/Response Extensions Draft [5], Mobile IP Network Access Identifier Extensions Draft[6], or Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network Draft [7]. 5. Security Considerations This document assumes that the Mobile IP messages are authenticated using a method defined by the Mobile IP protocol. This proposal 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. 6. Acknowledgments The authors would like to thank TR45.4 WG, TR45.6 WG, Basavaraj Patil, Jouni Malinen, and Patrice Calhoun for their useful discussions. 7. References [1] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [3] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May 1998. [4] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for Mobile IP. RFC 2356, June 1998. [5] Charles E. Perkins and Pat R. Calhoun. Mobile IP Challenge/Response Extensions. draft-ietf-mobileip-challenge-06.txt, Octobre 1999. [6] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network Address Identifier Extension. draft-ietf-mobileip-mn-nai-04.txt, September 1999. (work in progress). [7] Yingchun Xu and et. al. Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network. draft-ietf-mobileip-3gwireless-ext-00.txt, October 1999. [8] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Dommety, Leung [Page 4] Internet Draft Mobile IP Vendor-Specific Extensions November 1999 Author Information Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: gdommety@cisco.com Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: kleung@cisco.com Dommety, Leung