Movatterモバイル変換

Network Working Group                                         G. DommetyRequest for Comments: 3115                                      K. LeungObsoletes:3025                                            cisco SystemsCategory: Standards Track                                     April 2001Mobile IP Vendor/Organization-Specific ExtensionsStatus 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 inRFC 3025 and in the Internet   Assigned Numbers Authority's (IANA) repository.  The difference in   the assigned values are as follows:   CVSE-TYPE-NUMBER = 37 inRFC 3025   CVSE-TYPE-NUMBER = 38 in IANA (Under Mobile IP numbers)   NVSE-TYPE-NUMBER =  133 inRFC 3025   NVSE-TYPE-NUMBER =  134 in IANA (Under Mobile IP numbers)   This memo obsoletesRFC 3025, since the current implementations   follow the IANA assignments.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.Dommety & Leung             Standards Track                     [Page 1]

RFC 3115          Mobile IP Vendor Specific Extensions        April 20011. 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 inRFC 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.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.Dommety & Leung             Standards Track                     [Page 2]

RFC 3115          Mobile IP Vendor Specific Extensions        April 20012.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 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 [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 toRFC2002 [1], the entire packet is to be silently dropped.Dommety & Leung             Standards Track                     [Page 3]

RFC 3115          Mobile IP Vendor Specific Extensions        April 20012.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 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 [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.Dommety & Leung             Standards Track                     [Page 4]

RFC 3115          Mobile IP Vendor Specific Extensions        April 20012.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.   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 toRFC 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.Dommety & Leung             Standards Track                     [Page 5]

RFC 3115          Mobile IP Vendor Specific Extensions        April 20012.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.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   inSection 2.1 and Normal Vendor/Organization Specific Extension   (NVSE) as defined insection 2.2 are proposed new extensions to the   Mobile IP protocol, defined inRFC 2002 [1] and extended inRFC 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].Dommety & Leung             Standards Track                     [Page 6]

RFC 3115          Mobile IP Vendor Specific Extensions        April 2001   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.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.Dommety & Leung             Standards Track                     [Page 7]

RFC 3115          Mobile IP Vendor Specific Extensions        April 20018. 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.comDommety & Leung             Standards Track                     [Page 8]

RFC 3115          Mobile IP Vendor Specific Extensions        April 20019. 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 9]