Subject: [MOBILE-IP] draft-ietf-mobileip-vendor-ext-05.txt

From: Gopal Dommety <[email-masked]>
Date: Tue, 7 Dec 1999 00:59:53 -0800

Hello:

        Sorry for the delay. I modified the draft incorporating suggestions. Please let me know if you have any suggestions and comments.

Thanks
Regards,
Gopal

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

Expires May 2000

           Mobile IP Vendor/Organization-Specific Extensions
                draft-ietf-mobileip-vendor-ext-05.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  document proposes   two   new    extensions   to   Mobile
   IP [1]. 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                                                  [Page 1]

Internet Draft    Mobile IP Vendor-Specific Extensions       November 1999

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
   draft  proposes   two  extensions  that   can  be  used   for  making
   organization specific extensions by vendors/organizations for
   their own specific purposes.

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 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 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        |            Length             | Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Vendor/Org-ID                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Vendor-Type                     |    Opaque Data
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 1: Critical Vendor/Organization Specific Extension

   Type       38  (not skippable) (see [1])

   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-ID
              The high-order octet is 0 and the low-order 3 octets

Dommety, Leung                                                  [Page 2]

Internet Draft    Mobile IP Vendor-Specific Extensions       November 1999

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

   Vendor-Type
                Indicates the particular type of Extension.

   Opaque Data

              Vendor/organization specific data.  These data fields
              may be published in future RFCs.  The opaque data is
              zero or more octets.

   The actual format of the opaque data is site or application specific,
   and a robust implementation SHOULD support the field as undistinguished
   octets.

   The codification of the range of allowed usage of this field is
   outside the scope of this specification.  It is recommended that
   opaque data be encoded as a sequence of vendor type/vendor
   length/value fields.

   The length field of this extension is chosen to be two bytes long
   to allow for more than 248 bytes of Opaque Data. If an
   implementation  does not recognize the CVSE, according to RFC [1]
   the entire packet is to be silently dropped. But if an agent
   recognizes the CVSE, then it is aware of how to deal with
   the length size.

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/Org-ID (cont)                 |    Vendor-Type
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Vend-Type(cont)|                           Opaque Data
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: Normal Vendor/Organization Specific Extension

      Type       134 (skippable) (see [1])

      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-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-Type
                Indicates the particular type of Extension.

      Opaque Data
                 Vendor/organization specific data.  These data
                 fields may be publicized in future RFCs. The opaque
                 data is zero or more octets.

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  38
  (CVSE)   and  recognizes   it,   but  the   extension  contains   an
  unknown/unsupported vendor ID or does  not know how to interpret the
  opaque data or a part of  opaque data, 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/acknowledement message) with an extension of type 38
  (CVSE)   and  recognizes   it,  but   the  extensions   contains  an
  unknown/unsupported vendor ID or does  not know how to interpret the
  opaque  data  or a  part  of opaque  data,  the  packet is  silently
  discarded.

  When  a  Mobile IP  entity  receives  a  mobile IP  realted  message
  (registration  request/reply, advertisement/solicitation,  etc) with
  an extension of type 134 (NVSE) and recognizes it, but the extension
  contains an  unknown/unsupported vendor ID  or does not know  how to
  interpret the opaque data or  a part of opaque data, that particular
  extension is skipped.

  NOTE that  according to RFC  [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  draft  is  compliant   with  the  above
  specification and specifies  the action if the extension  of type 38
  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 will be used.

Registration denied by the Foreign agent:

        107: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Mobile Node to the
        Foreign Agent.

        108: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Home Agent to the
        Foreign Agent.

Registration denied by the Home agent:

        141: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Mobile Node to the Home Agent.

        142: Unsupported Vendor-ID or unable to interpret
        Opaque Data in the CVSE sent by the Foreign Agent to the Home Agent.

Dommety, Leung                                                  [Page 3]

Internet Draft    Mobile IP Vendor-Specific Extensions       November 1999

3. Restrictions

   Multiple TLV's with the types 38 and 134  can be included in a
   message.  TLVs with types 38 and 134  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  numbers for  the Vendor/Organization  Specific  extensions are
   taken from  the numbering space defined for  Mobile IP registration
   extensions defined  in RFC 2002  [1]. The number for  CVSE (section
   2.2) is taken from  the range 0-127 (not skippable)  and the number
   for   NVSE  (section  2.3)   is  taken   from  the   range  128-255
   (skippable). These MUST  NOT conflict with any numbers  used in RFC
   2002[1], RFC  2344 [3], RFC 2356 [4],  Mobile IP Challenge/Response
   Extensions   Draft  [5],  Mobile   IP  Network   Access  Identifier
   Extensions Draft[6],  or Mobile IP Based  Micro Mobility Management
   Protocol in  The Third Generation  Wireless Network Draft  [7]. The
   Code values specified  for errors, listed in section  2.5, MUST NOT
   conflict with any other code values listed in RFC 2002[1], RFC 2344
   [3],  RFC 2356  [4] Mobile  IP Challenge/Response  Extensions Draft
   [5], Mobile  IP Network  Access Identifier Extensions  Draft[6], or
   Mobile  IP Based Micro  Mobility Management  Protocol in  The Third
   Generation Wireless Network Draft [7].

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

6. IPv6 Considerations

   This extension can be used in IPv4 and IPv6 alike.

7. Acknowledgments

   The authors  would like  to thank TR45.4  WG, TR45.6  WG, Basavaraj
   Patil,  Jouni  Malinen,  and   Patrice  Calhoun  for  their  useful
   discussions.

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

   [3] G. Montenegro.  Reverse Tunneling for Mobile IP.  RFC 2344, May
       1998.

   [4] G. Montenegro and V. Gupta.  Sun's SKIP Firewall Traversal for
       Mobile IP.  RFC 2356, June 1998.

   [5] Charles  E. Perkins   and  Pat R. Calhoun.  Mobile   IP
       Challenge/Response Extensions. draft-ietf-mobileip-challenge-06.txt,
       Octobre 1999.

   [6] Pat R. Calhoun and Charles E. Perkins.  Mobile IP Network
       Address Identifier Extension. draft-ietf-mobileip-mn-nai-04.txt,
       September 1999.  (work in progress).

   [7] Yingchun Xu and et. al. Mobile IP  Based Micro Mobility Management
       Protocol in The  Third Generation Wireless Network.
       draft-ietf-mobileip-3gwireless-ext-00.txt, October 1999.

Dommety, Leung                                                  [Page 4]

Internet Draft    Mobile IP Vendor-Specific Extensions       November 1999

Author Information

   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: [email-masked]

   Kent Leung
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: [email-masked]

Dommety, Leung