    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]