diff options
Diffstat (limited to 'doc/rfc/rfc3025.txt')
| -rw-r--r-- | doc/rfc/rfc3025.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3025.txt b/doc/rfc/rfc3025.txt new file mode 100644 index 0000000..398127d --- /dev/null +++ b/doc/rfc/rfc3025.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group G. Dommety +Request for Comments: 3025 K. Leung +Category: Standards Track cisco Systems + February 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. + +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. + +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 document + defines 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 [3]. + + In addition, the following words are used to signify the requirements + of the specification. + + + + + +Dommety & Leung Standards Track [Page 1] + +RFC 3025 Mobile IP Vendor Specific Extensions February 2001 + + + 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 | Reserved | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor/Org-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-CVSE-Type | Vendor-CVSE-Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Critical Vendor/Organization Specific Extension + + Type CVSE-TYPE-NUMBER 37 + + 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. + + + + + + + +Dommety & Leung Standards Track [Page 2] + +RFC 3025 Mobile IP Vendor Specific Extensions February 2001 + + + 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-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 [1], the entire packet is to be silently dropped. + +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-NVSE-Type | Vendor-NVSE-Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Normal Vendor/Organization Specific Extension + + Type 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. + + + + + + + + +Dommety & Leung Standards Track [Page 3] + +RFC 3025 Mobile IP Vendor Specific Extensions February 2001 + + + 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-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. + +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 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. + + 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. + + 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. + + 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. + + + + + + + +Dommety & Leung Standards Track [Page 4] + +RFC 3025 Mobile IP Vendor Specific Extensions February 2001 + + + 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. + + 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. + + 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. + +2.4 Error Codes + + 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. + + 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. + + 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-2 141: Unsupported Vendor-ID or + unable to interpret Vendor-CVSE-Type in the CVSE sent by the + Foreign Agent to the Home Agent. + + + + + + + + + +Dommety & Leung Standards Track [Page 5] + +RFC 3025 Mobile IP Vendor Specific Extensions February 2001 + + +3. Restrictions + + 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. + +4. IANA Considerations + + 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]. + + 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 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]. + +5. Security Considerations + + 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. + +6. Acknowledgments + + 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. + + + + + + + + +Dommety & Leung Standards Track [Page 6] + +RFC 3025 Mobile IP Vendor Specific Extensions February 2001 + + +7. References + + [1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. + + [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May + 1998. + + [5] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for + Mobile IP", RFC 2356, June 1998. + +8. Authors' Addresses + + Gopal Dommety + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134 + + EMail: gdommety@cisco.com + + + Kent Leung + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134 + + EMail: kleung@cisco.com + + + + + + + + + + + + + + + + + + + +Dommety & Leung Standards Track [Page 7] + +RFC 3025 Mobile IP Vendor Specific Extensions February 2001 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + 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. + + + + + + + + + + + + + + + + + + + +Dommety & Leung Standards Track [Page 8] + |