Subject: [MOBILE-IP] Draft for Vendor/Organization Specific Extensions

From: Gopal Dommety <[email-masked]>
Date: Fri, 24 Sep 1999 10:23:13 -0700

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

            Vendor/Organization-Specific Extensions for Mobile IP
                  <draft-dommety-mobileip-vendor-ext-00.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 draft proposes an 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.

1.0   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  extensions that can be used for
   making organization specific extensions.

2.0 Vendor/Organization Specific Extensions

Two  Vendor/Organization Specific Extensions  are described,  Critical
and Normal    Vendor/Organization  Specific Extensions.     The  basic
differeces are between the Critical and  the Normal Extensions is that
whan 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 lenght feild of two bytes.

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

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

3.0 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  meggase.  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.0 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.

5.0 IPv6 considerations

        This extension can be used in IPv4 and IPv6 alike.

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.

Authors' Addresses

   Questions about this memo can be directed to:

      Gopal Dommety                     Kent Leung
      Cisco Systems                     Cisco Systems
      170 West Tasman Drive             170 West Tasman Drive
      San Jose, CA 95134                San Jose, CA 95134
      USA                               USA

      Phone:  +1-408-525-1404           Phone:  +1-408-526-5030
      EMail:  [email-masked]        EMail:  [email-masked]

---

From: Gopal Dommety <[email-masked]>
Date: Fri, 24 Sep 1999 10:25:41 -0700

Hello:

Attached (and also sent in the previous mail) is a preliminary draft:

Would really appreciate your comments.

Thanks.
-Gopal