One document matched: draft-ietf-mobileip-vendor-ext-00.txt

Mobile IP Working Group                                    Gopal Dommety
INTERNET DRAFT                                             Kent Leung
August 1999                                                Cisco Systems

Expires January 2000

           Mobile IP Vendor/Organization-Specific Extensions
                draft-ietf-mobileip-vendor-ext-00.txt

1. 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.

2. Abstract

   This draft proposes extensions that can be used as a vendor or
   organization-Specific Extensions.  These extensions will facilitate
   organizations to make specific extensions as they see fit for
   research or deployment purposes.

Dommety, Leung                                                  [Page 1]

Internet Draft    Mobile IP Vendor-Specific Extensions       August 1999

3. Introduction

   Current specification of Mobile IP [1] does not allow for
   organizations and vendor to include organization/vendor-specific
   extensions in the Mobile IP messages. With the wide scale deployment
   of Mobile IP it is useful to have a vendor or organization-Specific
   Extension.  This draft proposes an extension that can be used for
   making organization specific extensions.

4. Vendor/Organization Specific Extension

   Two Vendor/Organization Specific Extensions are described, Critical
   and Normal Vendor/Organization Specific Extensions.  The basic
   differences are between the Critical and Normal Extensions is 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
   and not recognized, the extension is 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 bytes.

4.1. Critical Vendor/Organization Specific Extension

   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             |   Vendor-ID
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Vendor-ID (cont)                 | Opaque Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 1: Vendor/Organization Specific Extension

   Type       TBD-1 (value should be in the range of 0-127)

   Length     Length in bytes of this extension, not including the
              Type and Length bytes.

   Vendor-ID
              The high-order octet is 0 and the low-order 3 octets

Dommety, Leung                                                  [Page 2]

Internet Draft    Mobile IP Vendor-Specific Extensions       August 1999

              are the SMI Network Management Private Enterprise Code
              of the Vendor in network byte order, as defined in the
              Assigned Numbers RFC [2].

   Opaque Data
              Vendor/organization specific data.  These data fields
              may be publicized in future RFCs.

4.2. Normal Vendor/Organization Specific Extension

   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     |   Vendor-ID
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Vendor-ID (cont)     | Opaque Data...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: Vendor/Organization Specific Extension

      Type       TBD-2 (value should be in the range of 128-255)

      Length     Length in bytes of this extension, not including the
                 Type and Length bytes.

      Vendor-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].

      Opaque Data
                 Vendor/organization specific data.  These data
                 fields may be publicized in future RFCs.

Dommety, Leung                                                  [Page 3]

Internet Draft    Mobile IP Vendor-Specific Extensions       August 1999

5. Restrictions

   Multiple TLV's with the TBD-1 and TBD-2 types can be included in a
   message. TLVs with TBD-1 and TBD-2 types 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.

6. 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.

7. IPv6 Considerations

   This extension can be used in IPv4 and IPv6 alike.

8. Acknowledgements

   To be supplied.

9. 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.

Dommety, Leung                                                  [Page 4]

Internet Draft    Mobile IP Vendor-Specific Extensions       August 1999

10. 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                 Expires January 2000               [Page 5]