RFC 5096

RFC 5096: Mobile IPv6 Experimental Messages 🦋

Okay bestie, the header is giving legit networking drama 💅 This is RFC 5096, written by Vijay Devarapalli from Azaire Networks. It's a Standards Track doc from the Network Working Group, dated December 2007 🎀. The header doesn't list any Obsoletes or Updates, so it isn't replacing or changing any other RFC 🌸

Status of This Memo ✨

This is a standards track protocol for the whole Internet community, and the IETF is literally asking for discussion and suggestions 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💜

Abstract 🌈

This doc defines a brand new experimental Mobility Header message, plus 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 💖

So when you're experimenting with a protocol, or building a new extension for one, you need a protocol number, a new message, or an option to carry your experiment's info 🍓 The problem is most implementations just grab unassigned values for their new messages. That gets messy when the same value ends up assigned through an IETF standards action or by IANA, or when the implementation gets deployed with those messages anyway 😭 So it's considered a good practice to set aside some code points that are only for experimental protocols or messages. The reasoning for this is shown in [3].

This doc defines new messages for experimenting with extensions to Mobile IPv6. These messages should be strictly used for experiments 🔬 Experiments that work out should get standardized in the IETF. An implementation MUST NOT be released or deployed with the experimental messages 🚫

This doc defines a new Mobility Header message, the Experimental Mobility message, which can be sent at any time by the mobile node, the home agent, or the correspondent node ✈️ Mobility Header messages can't be combined and sent in one packet, so there's always only one Mobility Header message in any Mobile IPv6 packet 💅 If a home agent or correspondent node doesn't recognize the mobility message type, it discards the message and sends a Binding Error message as described in [2], with the Status field set to 2 (unrecognized MH Type value) 🙈 Mobile nodes that don't recognize the mobility message type should discard the message and send an ICMP Parameter problem with code 0.

This doc also defines a new mobility option, the Experimental Mobility option, which can be carried in any Mobility Header message. By definition, mobility options can be skipped if an implementation doesn't recognize the mobility option type [2] 🦋

The messages in this doc can also be used for Network Mobility (NEMO) [4] and Proxy Mobile IPv6 [5], since those protocols also use Mobility Header messages 🌸

Experimental code points could potentially disrupt a deployed network when experiments using them run in that network 💀 So the network scope of support for experimental values should be carefully evaluated before you deploy any experiment across extended network domains, like 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. That limits the number of experiments among a set of peers to one at a time. Once experimental mechanisms are shown to be useful and there's 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1] 🧚

3. Experimental Mobility Header Message 🦋

The Experimental Mobility Header message is based on the Mobility Header message defined in Section 6.1 of RFC 3775 [2] 💜 It has no fields beyond the required fields in the Mobility Header. The 'MH Type' field in the Mobility Header indicates that it's an Experimental Mobility Header message ✨

If there's no data in the message, two bytes of padding are required 🙈 The 'Header Len' field in the Mobility Header is set to 0, since the first 8 octets are excluded when calculating the length of the Mobility Header message.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Payload Proto |  Header Len   |   MH Type     |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Checksum            |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    |                                                               |
    .                                                               .
    .                       Message Data                            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

See RFC 3775 [2] for a description of the 'Payload Proto', 'Header Len', 'MH Type', 'Reserved', and 'Checksum' fields 📚

The 'Message Data' field carries the data specific to the experimental protocol extension 🍓 The total length of the message is indicated by the 'Header Len' field in the Mobility Header.

4. Experimental Mobility Option 🌈

The Experimental Mobility option can be included in any Mobility Header message 🫶 If the Mobility Header message includes a Binding Authorization Data option [2], then the Experimental Mobility option should appear before the Binding Authorization Data option ⭐

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length      |        Data .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

An 8-bit field indicating that it's an experimental mobility option 🎀

Length

An 8-bit field indicating the length of the option in octets, excluding the Type and Length fields 💅

Data

Data related to the experimental protocol extension ✨

Intellectual Property ✨

okay bestie, so the IETF is basically saying "we're not picking a side on whether anyone owns the tech in here" 💅 They don't claim to know if there are patents or other rights tangled up in this stuff, and they haven't done a deep investigation to find out either 🙈 If you want the rules on how rights work for RFC documents, check out BCP 78 and BCP 79 📚

Like, if you're curious about IPR disclosures that were sent to the IETF Secretariat, or promises of licenses, or what happens when someone tries to get a general license or permission to use proprietary tech for implementing or using this spec, all of that lives in the IETF's online IPR repository at http://www.ietf.org/ipr 🎀

And the IETF is literally begging (in the nicest way) for anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech you need to implement this standard to tell them 🫶 Send that info to ietf-ipr@ietf.org and they'll take it from there 💖