Mobile IPv6 Experimental Messages
RFC 5096
Network Working Group V. Devarapalli
Request for Comments: 5096 Azaire Networks
Category: Standards Track December 2007
Mobile IPv6 Experimental Messages
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.
Abstract
This document defines a new experimental Mobility Header message and
a Mobility option that can be used for experimental extensions to the
Mobile IPv6 protocol.
Table of Contents
1. Introduction ....................................................1
2. Terminology .....................................................2
3. Experimental Mobility Header Message ............................3
4. Experimental Mobility Option ....................................3
5. Security Considerations .........................................4
6. IANA Considerations .............................................5
7. Acknowledgements ................................................5
8. References ......................................................5
8.1. Normative References .......................................5
8.2. Informative References .....................................5
1. Introduction
When experimenting with a protocol or defining a new extension to a
protocol, one needs either a protocol number, a new message, or an
option to carry the information related to the experiment. Most
implementations end up using unassigned values for the new messages.
Many times this creates problems when the same value is assigned
through the IETF standards action, by IANA, or if the implementation
gets deployed with these messages. Therefore, it is considered a
good practice to set aside some code points that identify the
experimental protocols or messages for experimental purposes. The
need for experimental messages is shown in [3].
Devarapalli Standards Track [Page 1]
RFC 5096 MIPv6 Experimental Messages December 2007
This document defines new messages for experimenting with extensions
to the Mobile IPv6 protocol. These messages should be strictly used
for experiments. Experiments that are successful should be
standardized in the IETF. An implementation MUST NOT be released or
deployed with the experimental messages.
This document defines a new Mobility Header message, which is the
Experimental Mobility message that can be sent at any time by the
mobile node, the home agent or the correspondent node. Since
Mobility Header messages cannot be combined and sent in one packet,
there is always only one Mobility Header message in any Mobile IPv6
packet. Home agent or correspondent node implementations that do not
recognize the mobility message type, discard the message and send a
Binding Error message as described in [2], with the Status field set
to 2 (unrecognized MH Type value). Mobile nodes that do not
recognize the mobility message type should discard the message and
send an ICMP Parameter problem with code 0.
This document also defines a new mobility option, the Experimental
Mobility option, which can be carried in any Mobility Header message.
Mobility options, by definition, can be skipped if an implementation
does not recognize the mobility option type [2].
The messages defined in this document can also be used for Network
Mobility (NEMO) [4] and Proxy Mobile IPv6 [5] since these protocols
also use Mobility Header messages.
Experimental code points could potentially disrupt a deployed network
when experiments using these code points are performed in the
network. Therefore, the network scope of support for experimental
values should carefully be evaluated before deploying any experiment
across extended network domains, such as the public Internet.
Experimental mechanisms should only be used for actual
experimentation. By design, only a single code point is allocated
for the message and another one for the option. This limits the
number of experiments among a set of peers to one at a time. When
experimental mechanisms are shown to be useful, and there is a desire
to deploy them beyond the experiment they should be standardized and
given new code points.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Show full document text