Browse Prior Art Database

Mobile IP Vendor/Organization-Specific Extensions (RFC3025)

IP.com Disclosure Number: IPCOM000005217D
Original Publication Date: 2001-Feb-01
Included in the Prior Art Database: 2001-Aug-17
Document File: 9 page(s) / 16K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G. Dommety: AUTHOR [+2]

Abstract

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 22% of the total text.

Network Working Group G. Dommety Request for Comments: 3025 K. Leung Category: Standards Track cisco Systems

February 2001

Mobile IP Vendor/Organization-Specific Extensions

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes.

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

Dommety Leung Standards Track [Page 1]

RFC 3025 Mobile IP Vendor Specific Extensions February 2001

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