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-06.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.
1.1. Specification Language
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means that
the definition is an absolute requirement of the
specification.
SHOULD This word, or the adjective "recommended", means
that, in some circumstances, valid reasons may exist
to ignore this item, but the full implications must
be understood and carefully weighed before choosing
a different course. Unexpected results may result
otherwise.
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 | 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. The
admistration of the Vendor-Types is done by the
Vendor.
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. It is recommended that opaque data be
encoded as a sequence of 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 are defined.
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. Acknowledgments
The authors would like to thank TR45.4 WG, TR45.6 WG, Basavaraj
Patil, Jouni Malinen, and Patrice Calhoun for their useful
discussions.
7. 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: gdommety@cisco.com
Kent Leung
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
e-mail: kleung@cisco.com
Dommety, Leung
