Mobile IP Vendor/Organization-Specific Extensions
obsoletes
- rfc-3025 — Mobile IP Vendor/Organization-Specific Extensions
Extracted elements (18)
The Vendor/Org-ID field uses the SMI Network Management Private Enterprise Code (with high-order octet set to 0) rather than a new registry, leveraging an existing globally administered namespace to uniquely identify vendors without requiring IANA to manage vendor identities for these extensions.
Two separate extensions (Critical and Normal) were defined because different failure behaviors are needed: unrecognized CVSEs require dropping the entire message (to prevent unsafe operation with unknown critical vendor behavior), whereas unrecognized NVSEs can be safely skipped without disrupting message processing. The CVSE also uses a two-octet length field versus NVSE's one-octet field to support larger payloads.
RFC 3115 obsoletes RFC 3025 to correct type number discrepancies: CVSE-TYPE-NUMBER was assigned 37 in RFC 3025 but 38 by IANA; NVSE-TYPE-NUMBER was 133 in RFC 3025 but 134 by IANA. Current implementations follow the IANA assignments, making the correction necessary.
Per RFC 2002, extensions numbered 0–127 in a registration message that are not recognized MUST be silently discarded. Since CVSE-TYPE-NUMBER 38 falls in this range, RFC 3115 is compliant with RFC 2002 and additionally specifies behavior when the extension is recognized but the vendor ID or vendor type within is unknown.
RFC 3115 obsoletes RFC 3025 because implementations followed the IANA-assigned type numbers (CVSE=38, NVSE=134) rather than the values in RFC 3025 (CVSE=37, NVSE=133). Implementations conforming to RFC 3025's numeric values are incompatible with RFC 3115-conformant implementations.
Ordering of CVSE and NVSE TLVs SHOULD NOT be modified by intermediate nodes. These TLVs are expected to be protected by the corresponding authenticator as necessary.
The Reserved field in the CVSE MUST be set to 0 on sending and MUST be ignored on reception.
When a Mobile IP entity receives a message with an unrecognized NVSE extension (unknown Vendor-ID or Vendor-NVSE-Type), the entire NVSE extension is skipped, but the rest of the extensions and message data MUST still be processed.
When a Mobile IP entity receives a registration request (or other request/update) containing a recognized CVSE with an unknown or unsupported Vendor-ID or Vendor-CVSE-Type, it MUST send a registration reject with the appropriate error code.
When a transit Mobile IP entity receives a registration reply containing a recognized CVSE with an unknown or unsupported Vendor-ID or Vendor-CVSE-Type, it MUST send a registration reject to the next entity (e.g., FA rejects to MN upon receiving an unknown CVSE from HA).
When silently discarding a datagram, the implementation SHOULD provide the capability of logging the error including the discarded datagram contents, and SHOULD record the event in a statistics counter.
Four error codes are defined for CVSE processing failures: ERROR-FA-1 (code 100, unsupported Vendor-ID or Vendor-CVSE-Type in CVSE from MN to FA), ERROR-FA-2 (code 101, unsupported Vendor-ID or Vendor-CVSE-Type in CVSE from HA to FA), ERROR-HA-1 (code 140, from MN to HA), ERROR-HA-2 (code 141, from FA to HA).
The Critical Vendor/Organization Specific Extension (CVSE) allows vendors to include organization-specific data in Mobile IP messages. When an unrecognized CVSE is encountered, the entire message containing it MUST be silently discarded. CVSE is assigned Type number 38.
The Normal Vendor/Organization Specific Extension (NVSE) allows vendors to include organization-specific data in Mobile IP messages. When an unrecognized NVSE is encountered, the extension SHOULD be ignored but the rest of the message MUST still be processed. NVSE is assigned Type number 134.
IANA assigned CVSE-TYPE-NUMBER = 38 and NVSE-TYPE-NUMBER = 134, both taken from the Mobile IP registration extensions numbering space defined in RFC 2002. IANA also assigned Foreign Agent error codes ERROR-FA-1 (100) and ERROR-FA-2 (101), and Home Agent error codes ERROR-HA-1 (140) and ERROR-HA-2 (141) from their respective Mobile IP error code numbering spaces.
RFC 3115 assumes that Mobile IP messages are authenticated using methods defined by the Mobile IP protocol (RFC 2002). No additional security requirements are imposed by this document beyond those already in Mobile IP, and CVSE/NVSE TLVs are expected to be covered by existing Mobile IP authenticators.
The CVSE wire format comprises: Type (1 octet, value 38), Reserved (1 octet, must be zero), Length (2 octets, excludes Type and Length bytes), Vendor/Org-ID (4 octets, high-order octet 0 followed by SMI Network Management Private Enterprise Code in network byte order), Vendor-CVSE-Type (2 octets), and variable-length Vendor-CVSE-Value.
The NVSE wire format comprises: Type (1 octet, value 134), Length (1 octet, excludes Type and Length bytes), Reserved (2 octets, set to 0), Vendor/Org-ID (4 octets, high-order octet 0 followed by SMI Private Enterprise Code in network byte order), Vendor-NVSE-Type (2 octets), and variable-length Vendor-NVSE-Value.