As per Relevance of the word extension, we have this rfc below:
Network Working Group G.
Request for Comments: 3025 K.
Category: Standards Track cisco
February 2001
Mobile IP Vendor/Organization-Specific
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document defines two new extensions to Mobile IP.
extensions will facilitate equipment vendors and organizations
make specific use of these extensions as they see fit for research
deployment purposes
1.
Current specification of Mobile IP [1] does not allow
organizations and vendors to include organization/vendor-
information in the Mobile IP messages. With the imminent wide
deployment of Mobile IP it is useful to have vendor or organization
Specific Extensions to support this capability. This
defines two extensions that can be used for making
specific extensions by vendors/organizations for their own
purposes
1.1. Specification
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [3].
In addition, the following words are used to signify the
of the specification
Dommety & Leung Standards Track [Page 1]
RFC 3025 Mobile IP Vendor Specific Extensions February 2001
silently
The implementation discards the datagram without
processing, and without indicating an error to the sender
The implementation SHOULD provide the capability of
the error, including the contents of the discarded datagram
and SHOULD record the event in a statistics counter
2. Vendor/Organization Specific
Two Vendor/Organization Specific Extensions are described,
(CVSE) and Normal (NVSE) Vendor/Organization Specific Extensions
The basic differences between the Critical and Normal Extensions
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
encountered but not recognized, the extension SHOULD be ignored,
the rest of the Extensions and message data MUST still be processed
Another difference between the two is that
Vendor/Organization Extension has a length field of two octets
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
Type CVSE-TYPE-NUMBER 37
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
and Length bytes
Dommety & Leung Standards Track [Page 2]
RFC 3025 Mobile IP Vendor Specific Extensions February 2001
Vendor/Org-
The high-order octet is 0 and the low-order 3 octets
the SMI Network Management Private Enterprise Code of
Vendor in network byte order, as defined in the
Numbers RFC [2].
Vendor-CVSE-
Indicates the particular type of Vendor-CVSE-Extension
The administration of the Vendor-CVSE-Types is done by
Vendor
Vendor-CVSE-
Vendor/organization specific data of this Vendor-CVSE
Extension. These data fields may be published in
RFCs. The Vendor-CVSE-Value is zero or more octets.
length of this field can be computed from the Length
Value
If an implementation does not recognize the CVSE, according to
2002 [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
Type NVSE-TYPE-NUMBER 133
Length Length in bytes of this extension, not including the
and Length bytes
Reserved Reserved for future use. To be set to 0.
Dommety & Leung Standards Track [Page 3]
RFC 3025 Mobile IP Vendor Specific Extensions February 2001
Vendor/Org-
The high-order octet is 0 and the low-order 3 octets
the SMI Network Management Private Enterprise Code of
Vendor in network byte order, as defined in the
Numbers RFC [2].
Vendor-NVSE-Type Indicates the particular type of Vendor-NVSE
Extension. The administration of the Vendor-NVSE-Types
done by the Vendor
Vendor-NVSE-
Vendor/organization specific data of this Vendor-NVSE
Extension. These data fields may be published in
RFCs. The Vendor-NVSE-Value is zero or more octets.
length of this field can be computed from the
Field Value
2.3 Vendor/Organization Specific Extensions Processing
When a Mobile IP entity receives a registration request message (
any other request/update message) with an extension of type CVSE
TYPE-NUMBER and recognizes it, but the extension contains
unknown/unsupported vendor ID or Vendor-CVSE-Type, a
reject (or the appropriate deny message) MUST be sent with the
code to indicate that the registration was rejected due to
presence of an unknown CVSE
When a Mobile IP entity receives a registration reply (or any
mobile IP reply/acknowledgement message) with an extension of
CVSE-TYPE-NUMBER and recognizes it, but the extensions contains
unknown/unsupported vendor ID or Vendor-CVSE-Type, the processing
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
entity) a registration reject (or the appropriate deny message)
be sent with the error code to indicate that the registration
rejected due to the presence of an unknown CVSE. For example,
when it receives an unknown 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,
reply is treated as a reject (or the appropriate deny message) due
the presence of an unknown CVSE
Dommety & Leung Standards Track [Page 4]
RFC 3025 Mobile IP Vendor Specific Extensions February 2001
While designing enhancements wherein a CVSE is included in a
message, it should noted that the reply message could be discarded
the mobile IP entity processing this message. Enhancements
include a CVSE should take this into consideration during design
When a Mobile IP entity receives a mobile IP related
(registration request/reply, advertisement/solicitation, etc.)
an extension of type NVSE-TYPE-NUMBER and recognizes it, but
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
within the range 0 through 127 is encountered in a
message but not recognized, the message containing that
MUST be silently discarded. This document is compliant with
above specification and specifies the action if the extension of
CVSE-TYPE-NUMBER is encountered and recognized, but does not
the vendor ID or the vendor type extension within
2.4 Error
The following error codes are defined
Registration denied by the Foreign agent
ERROR-FA-1 100: Unsupported Vendor-ID
unable to interpret Vendor-CVSE-Type in the CVSE sent by
Mobile Node to the Foreign Agent
ERROR-FA-2 101: Unsupported Vendor-ID
unable to interpret Vendor-CVSE-Type in the CVSE sent by
Home Agent to the Foreign Agent
Registration denied by the Home agent
ERROR-HA-1 140: Unsupported Vendor-ID
unable to interpret Vendor-CVSE-Type in the CVSE sent by
Mobile Node to the Home Agent
ERROR-HA-2 141: Unsupported Vendor-ID
unable to interpret Vendor-CVSE-Type in the CVSE sent by
Foreign Agent to the Home Agent
Dommety & Leung Standards Track [Page 5]
RFC 3025 Mobile IP Vendor Specific Extensions February 2001
3.
Multiple TLV's with the types CVSE-TYPE-NUMBER and NVSE-TYPE-
can be included in a message. TLVs with types CVSE-TYPE-NUMBER
NVSE-TYPE-NUMBER can be placed anywhere after the fixed portion
the Mobile IP message. These TLVs are expected to be protected
the corresponding authenticator as necessary. Ordering of
TLV's should not be modified by intermediate nodes
4. IANA
The Critical Vendor/Organization Specific Extension (CVSE) as
in Section 2.1 and Normal Vendor/Organization Specific
(NVSE) as defined in section 2.2 are proposed new extensions to
Mobile IP protocol, defined in RFC 2002 [1] and extended in RFC 2356
[5].
IANA has assigned a Type value of CVSE-TYPE-NUMBER for the
Vendor/Organization Specific Extension (CVSE), and a Type value
NVSE-TYPE-NUMBER for the Normal Vendor/Organization
Extension (NVSE). The numbers CVSE-TYPE-NUMBER and NVSE-TYPE-
for the CVSE and the NVSE are taken from the numbering space
for Mobile IP registration extensions [1].
IANA has assigned new Foreign Agent Error Codes, ERROR-FA-1
ERROR-FA-2 taken from the numbering space defined for Mobile
Foreign Agent error codes [1]. IANA has also assigned new Home
Error Codes, ERROR-HA-1 and ERROR-HA-2 taken from the numbering
defined for Mobile IP Home Agent error codes [1].
5. Security
This document assumes that the Mobile IP messages are
using a method defined by the Mobile IP protocol. This document
not impose any additional requirements on Mobile IP messages from
security point of view. So this is not expected to be a
issue
6.
The authors would like to thank TR45.4 WG, TR45.6 WG,
Patil, Phil Roberts, Jouni Malinen, and Patrice Calhoun for
useful discussions
Dommety & Leung Standards Track [Page 6]
RFC 3025 Mobile IP Vendor Specific Extensions February 2001
7.
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[3] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[4] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344,
1998.
[5] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal
Mobile IP", RFC 2356, June 1998.
8. Authors'
Gopal
Cisco Systems, Inc
170 West Tasman
San Jose, CA 95134
EMail: gdommety@cisco.
Kent
Cisco Systems, Inc
170 West Tasman
San Jose, CA 95134
EMail: kleung@cisco.
Dommety & Leung Standards Track [Page 7]
RFC 3025 Mobile IP Vendor Specific Extensions February 2001
9. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Dommety & Leung Standards Track [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
