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]
