One document matched: draft-ietf-mobileip-vendor-ext-11.txt-14043.txt
Differences from 11.txt-10.txt
Mobile IP Working Group Gopal Dommety
INTERNET DRAFT Kent Leung
September 2000 cisco Systems
Expires February 2001
Mobile IP Vendor/Organization-Specific Extensions
draft-ietf-mobileip-vendor-ext-11.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 defines 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 February 2001
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 defines two extensions that can be used for making
organization specific extensions by vendors/organizations for
their own specific purposes.
1.1. Specification Language
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [3].
In addition, the following words are used to signify the requirements
of the specification.
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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-CVSE-Type | Vendor-CVSE-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Critical Vendor/Organization Specific Extension
Type CVSE-TYPE-NUMBER (To be assigned by IANA)
Reserved Reserved for future use. MUST be set to 0 on sending,
MUST be ignored on reception.
Length Length in bytes of this extension, not including the
Type and Length bytes.
Vendor/Org-ID
The high-order octet is 0 and the low-order 3 octets
Dommety, Leung [Page 2]
Internet Draft Mobile IP Vendor-Specific Extensions February 2001
are the SMI Network Management Private Enterprise Code
of the Vendor in network byte order, as defined in the
Assigned Numbers RFC [2].
Vendor-CVSE-Type
Indicates the particular type of Vendor-CVSE-Extension. The
administration of the Vendor-CVSE-Types is done by the
Vendor.
Vendor-CVSE-Value
Vendor/organization specific data of this Vendor-CVSE-Extension.
These data fields may be published in future RFCs. The
Vendor-CVSE-Value is zero or more octets. The length
of this field can be computed from the Length Feild Value.
If an implementation does not recognize the CVSE, according to RFC [1]
the entire packet is to be silently dropped.
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-NVSE-Type | Vendor-NVSE-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Normal Vendor/Organization Specific Extension
Type NVSE-TYPE-NUMBER (To be assigned by IANA)
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/Org-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-NVSE-Type
Indicates the particular type of Vendor-NVSE-Extension.
The administration of the Vendor-NVSE-Types is done by the
Vendor.
Vendor-NVSE-Value
Vendor/organization specific data of this Vendor-NVSE-Extension.
These data fields may be published in future RFCs. The
Vendor-NVSE-Value is zero or more octets. The
length of this field can be computed from the Length Feild
Value.
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
CVSE-TYPE-NUMBER and recognizes it, but the extension contains an
unknown/unsupported vendor ID or Vendor-CVSE-Type, 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/acknowledgement message) with an extension of type
CVSE-TYPE-NUMBER and recognizes it, but the extensions contains an
unknown/unsupported vendor ID or Vendor-CVSE-Type, the processing is
performed as described below.
1. If the Mobile IP entity is a transit node for the reply (i.e, this
entity processes and sends the registration reply to another entity)
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. For example, FA when it receives an
un understood CVSE in a registration reply from the HA, should send a
registration reject to the MN.
2. If the Mobile IP entity is not a transit node for the reply, the
reply is treated as a reject (or the appropriate deny message) due to
the presence of an unknown CVSE.
While designing enhancements wherein a CVSE is included in a reply
message, it should noted that the reply message could be discarded
by the mobile IP entity processing this message. Enhancements that
include a CVSE should take this into consideration during design.
When a Mobile IP entity receives a mobile IP related message
(registration request/reply, advertisement/solicitation, etc) with
an extension of type NVSE-TYPE-NUMBER and recognizes it, but the extension
contains an unknown/unsupported vendor ID or Vendor-NVSE-Type, the
entire extension is skipped.
NOTE that according to RFC 2002 [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
CVSE-TYPE-NUMBER 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:
ERROR-FA-1 (To be assigned by IANA): Unsupported Vendor-ID or
unable to interpret Vendor-CVSE-Type in the CVSE sent by the
Mobile Node to the Foreign Agent.
ERROR-FA-2 (To be assigned by IANA): Unsupported Vendor-ID or
unable to interpret Vendor-CVSE-Type in the CVSE sent by the
Home Agent to the Foreign Agent.
Registration denied by the Home agent:
ERROR-HA-1 (To be assigned by IANA): Unsupported Vendor-ID or
unable to interpret Vendor-CVSE-Type in the CVSE sent by the
Mobile Node to the Home Agent.
ERROR-HA-2 (To be assigned by IANA): Unsupported Vendor-ID or
unable to interpret Vendor-CVSE-Type in the CVSE sent by the
Foreign Agent to the Home Agent.
Dommety, Leung [Page 3]
Internet Draft Mobile IP Vendor-Specific Extensions February 2001
3. Restrictions
Multiple TLV's with the types CVSE-TYPE-NUMBER and NVSE-TYPE-NUMBER
can be included in a message. TLVs with types CVSE-TYPE-NUMBER and
NVSE-TYPE-NUMBER 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 Critical Vendor/Organization Specific Extension (CVSE) as
defined in Section 2.1 and Normal Vendor/Organization Specific
Extension (NVSE) as defined in section 2.2 are proposed new
extensions to the Mobile IP protocol, defined in RFC 2002 [1] and
extended in RFC 2356 [5].
The Authors request IANA to assign the Type value of CVSE-TYPE-NUMBER
for the Critical Vendor/Organization Specific Extension (CVSE), and a
Type value of NVSE-TYPE-NUMBER for the Normal Vendor/Organization
Specific Extension (NVSE). The numbers CVSE-TYPE-NUMBER and
NVSE-TYPE-NUMBER for the CVSE and the NVSE are taken from the
numbering space defined for Mobile IP registration extensions [1].
CVSE-TYPE-NUMBER should be allocated one of the values 0 through
127 and NVSE-TYPE-NUMBER should be allocated one of the values 128
through 255 [1].
The Authors request IANA to assign new Foreign Agent Error Codes,
ERROR-FA-1 and ERROR-FA-2 taken from the numbering space defined
for Mobile IP Foregin Agent error codes [1]. The Authors request
IANA to also assign new Home Agent Error Codes, ERROR-HA-1 and
ERROR-HA-2 taken from the numbering space defined for Mobile IP
Home Agent error codes [1].
5. Security Considerations
This document assumes that the Mobile IP messages are authenticated
using a method defined by the Mobile IP protocol. This document 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, Phil Roberts, 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] Bradner S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[4] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May
1998.
[5] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for
Mobile IP. RFC 2356, June 1998.
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
| PAFTECH AB 2003-2026 | 2026-04-21 22:07:22 |