Mobile IPv6 Experimental Messages
Extracted elements (15)
Experimental message code points are defined to avoid the common practice of using unassigned values in experiments, which creates problems when those values are later assigned through IETF standards action or when experimental implementations get deployed.
Only a single code point is allocated for the experimental message and one for the option, intentionally limiting concurrent experiments among a set of peers to one at a time. This is by design to prevent proliferation of unregistered experimental values.
Home agent or correspondent node implementations that do not recognize the Experimental Mobility Header message type discard the message and send a Binding Error with Status field set to 2 (unrecognized MH Type value). Mobile nodes that do not recognize it should discard and send an ICMP Parameter Problem with code 0.
Mobility options, by definition, can be skipped if an implementation does not recognize the mobility option type, so unrecognized Experimental Mobility options are silently ignored by receivers.
The Experimental Mobility Header message and option can also be used for Network Mobility (NEMO) and Proxy Mobile IPv6 since those protocols also use Mobility Header messages.
An implementation MUST NOT be released or deployed with the experimental messages defined in this document. These messages are strictly for experimentation only.
If the Mobility Header message includes a Binding Authorization Data option, the Experimental Mobility option should appear before the Binding Authorization Data option.
The Experimental Mobility Header message (MH Type = 11) can be sent at any time by the mobile node, home agent, or correspondent node, and carries experiment-specific data in the Message Data field.
The Experimental Mobility option (Type = 18) can be included in any Mobility Header message and carries data related to an experimental protocol extension.
The Experimental Mobility Header message is assigned MH Type value 11, allocated from the Mobility Header MH Type space defined in RFC 3775. The Experimental Mobility option is assigned type value 18, allocated from the Mobility Options space.
If experimental messages 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, they should be protected similarly to Binding Updates and Binding Acknowledgements.
Security analyzers such as firewalls and network intrusion detection monitors may fail or forward unrecognized experimental traffic, potentially causing loss of connectivity or loss of security if the new values are used as part of an attack.
When experimental code points cross multiple administrative domains, experimenters should assume a risk that the same code points will be used simultaneously by other experiments, potentially causing interference and security threats. Within a single administrative domain, each code point must be used consistently.
The Experimental Mobility Header message follows the standard Mobility Header format with fields: Payload Proto (8-bit), Header Len (8-bit), MH Type (8-bit, value 11), Reserved (8-bit), Checksum (16-bit), and variable-length Message Data. If no data is present, two bytes of padding are required; Header Len is set to 0 (excluding first 8 octets from length calculation).
The Experimental Mobility option has three fields: Type (8-bit, value 18), Length (8-bit, indicating length of option in octets excluding Type and Length fields), and variable-length Data carrying experiment-specific information.