Mobile IPv6 Vendor Specific Option
Extracted elements (14)
Extensions using the vendor-specific mobility option should require an indication that the option was processed in the response (also using a vendor-specific mobility option), since the base protocol only guarantees that unrecognized options are skipped, not acknowledged.
The vendor-specific option is intentionally limited to simple use cases where including vendor data in standardized MIPv6 exchanges is sufficient; it is not suitable for more complex extensions that modify Mobile IPv6 itself, because RFC 3775 requires that unrecognized options be ignored.
Implementations that do not recognize the Vendor ID either discard or skip processing the vendor-specific option; per RFC 3775, mobility options can be skipped if an implementation does not recognize the option type.
The Vendor-Specific Mobility Option can also be used with NEMO (RFC 3963) and Proxy MIPv6, since these protocols also use Mobility Header messages.
Complex vendor extensions that modify Mobile IPv6 itself, will see large-scale deployment, or involve industry consortia or other multi-vendor organizations MUST be standardized in the IETF.
If the Mobility Header message includes a Binding Authorization Data option, the Vendor-Specific mobility option should appear before the Binding Authorization Data option.
Messages containing the Vendor-Specific mobility option MUST be integrity protected, similar to Binding Updates and Binding Acknowledgements, especially when carrying sensitive information or data that can affect binding cache entries.
Multiple Vendor-Specific mobility options MAY be present in a single Mobility Header message.
The Vendor-Specific mobility option MUST be used only with a Mobility Header message.
The Sub-Type field is an 8-bit field indicating the type of vendor-specific information carried in the option; its administration is done entirely by the vendor, not by IANA.
The Vendor ID field in the option carries the SMI Network Management Private Enterprise Code from the IANA-maintained Private Enterprise Numbers registry, uniquely identifying the vendor.
The Vendor-Specific mobility option has been assigned type value 19, allocated from the Mobility Options registry created by RFC 3775.
Vendor-Specific mobility messages should be protected in a manner similar to Binding Updates and Binding Acknowledgements if they carry information that should not be revealed on the wire or that can affect the binding cache entry at the home agent or correspondent node.
The Vendor-Specific Mobility Option contains: Type (8-bit), Length (8-bit, excluding Type and Length fields), Vendor ID (32-bit SMI Network Management Private Enterprise Code), Sub-Type (8-bit, vendor-administered), and variable-length Data. The option has an alignment requirement of 4n+2.