RFC 5444
Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
Part 1 of 14 🎀
Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format 🦋
okay bestie, this is RFC 5444 💅 It's a Standards Track doc from February 2009, and it's by T. Clausen (LIX, Ecole Polytechnique), C. Dearlove (BAE Systems ATC), J. Dean (Naval Research Laboratory) and C. Adjih (INRIA Rocquencourt). The title block doesn't list any RFCs it obsoletes or updates, so it's standing on its own, no cap 🫶
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. 💜
Copyright Notice 🌈
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 📜
Abstract 🍓
This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. Basically it's a packet that can hold a whole bundle of messages for routing protocols to use 🧚
Table of Contents 📋
1. Introduction ....................................................3
2. Notation and Terminology ........................................4
2.1. Notation ...................................................4
2.1.1. Elements ............................................4
2.1.2. Variables ...........................................5
2.2. Terminology ................................................5
3. Applicability Statement .........................................6
4. Protocol Overview and Functioning ...............................7
5. Syntactical Specification .......................................7
5.1. Packets ....................................................8
5.2. Messages ...................................................9
5.3. Address Blocks ............................................11
5.4. TLVs and TLV Blocks .......................................14
5.4.1. TLVs ...............................................14
5.4.2. TLV Usage ..........................................17
5.5. Malformed Elements ........................................18
6. IANA Considerations ............................................18
6.1. Expert Review: Evaluation Guidelines ......................18
6.2. Message Types .............................................20
6.2.1. Message-Type-Specific TLV Registry Creation ........20
6.3. Packet TLV Types ..........................................21
6.3.1. Packet TLV Type Extension Registry Creation ........21
6.4. Message TLV Types .........................................21
6.4.1. Message TLV Type Extension Registry Creation .......22
6.5. Address Block TLV Types ...................................22
6.5.1. Address Block TLV Type Extension Registry
Creation ...........................................23
7. Security Considerations ........................................23
7.1. Authentication and Integrity Suggestions ..................23
7.2. Confidentiality Suggestions ...............................24
8. Contributors ...................................................25
9. Acknowledgments ................................................25
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
Appendix A. Multiplexing and Demultiplexing .......................28
Appendix B. Intended Usage ........................................28
Appendix C. Examples ..............................................30
C.1. Address Block Examples ....................................30
C.2. TLV Examples ..............................................32
Appendix D. Illustrations .........................................34
D.1. Packet ....................................................34
D.2. Message ...................................................38
D.3. Message Body ..............................................44
D.4. Address Block .............................................45
D.5. TLV Block .................................................52
D.6. TLV .......................................................53
Appendix E. Complete Example ......................................571. Introduction ✨
okay so this doc is all about the syntax of a packet format built for carrying multiple routing protocol messages, so MANET (Mobile Ad hoc NETwork) routers can swap info 🦋 Each message has a Message Header, which is there for controlling how the message gets spread around, and a Message Body, which holds the actual protocol info. Only the syntax of the packets and messages is specified here, nothing else 💅
This document specifies:
- A packet format, allowing zero or more messages to be contained within a single transmission. A packet with zero messages may be sent in case the only information to exchange is contained in the Packet Header. 🎀
- A message format, where a message is composed of a Message Header and a Message Body. 🌸
- A Message Header format, which contains information that may be sufficient to allow a protocol using this specification to make processing and forwarding decisions. 🧚
- A Message Body format, containing attributes associated with the message or the originator of the message, as well as blocks of addresses, or address prefixes, with associated attributes. 💜
- An Address Block format, where an Address Block represents sets of addresses, or address prefixes, in a compact form with aggregated addresses. 🍓
- A generalized type-length-value (TLV) format representing attributes. Each TLV can be associated with a packet, a message, or one or more addresses or address prefixes in a single Address Block. Multiple TLVs can be included, each associated with a packet, a message, and the same, different, or overlapping sets of addresses or address prefixes. 🌈
The specification has been explicitly designed with the following properties, listed in no particular order, in mind:
Parsing logic - The notation used in this specification facilitates generic, protocol-independent parsing logic. 🧠
Extensibility - Packets and messages defined by a protocol using this specification are extensible by defining new messages and new TLVs. Protocols using this specification will be able to correctly identify and skip such new messages and TLVs, while correctly parsing the remainder of the packet and message. 🔥
Efficiency - When reported addresses share common bit sequences (e.g., address prefixes or IPv6 interface identifiers), the Address Block representation allows for a compact representation. Compact Message Headers are ensured through permitting inclusion of only required Message Header elements. The multi-message packet structure allows a reduction in the number of transmitted octets and in the number of transmitted packets. The structure of packet and message encoding allows parsing, verifying, and identifying individual elements in a single pass. ⭐
Separation of forwarding and processing - A protocol using this specification can be designed such that duplicate detection and controlled-scope message forwarding decisions can be made using information contained in the Message Header, without processing the Message Body. 👑
2. Notation and Terminology 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Additionally, this document uses the notation in Section 2.1 and the terminology in Section 2.2. 🎀
2.1. Notation 🌸
The following notations, for elements and variables, are used in this document.
This format uses network byte order (most significant octet first) for all fields. The most significant bit in an octet is numbered bit 0, and the least significant bit of an octet is numbered bit 7 [Stevens]. 🧚
2.1.1. Elements 💜
This specification defines elements. An element is a group of any number of consecutive bits that together form a syntactic entity represented using the notation <element>. Each element in this document is defined as either:
- a specifically sized field of bits OR
- a composite element, composed of other <element>s.
A composite element is defined as follows:
<element> := specificationwhere, on the right hand side following :=, specification is represented using the regular expression syntax defined in [SingleUNIX]. Only the following notation is used:
<element1><element2>- Indicates that <element1> is immediately followed by <element2>.(<element1><element2>)- Indicates a grouping of the elements enclosed by the parentheses.?- Zero or one occurrences of the preceding element or group.*- Zero or more occurrences of the preceding element or group. 🍓
2.1.2. Variables 🌈
Variables are introduced into the specification solely as a means to clarify the description. The following two notations are used:
<foo>- If <foo> is an unsigned integer field, then <foo> is also used to represent the value of that field.bar- A variable, usually obtained through calculations based on the value(s) of element(s).
2.2. Terminology 🦋
This document uses the following terminology:
Packet - The top level entity in this specification. A packet contains a Packet Header and zero or more messages. 📦
Message - The fundamental entity carrying protocol information, in the form of address objects and TLVs. 💌
Address - A number of octets that make up an address of the length indicated by the encapsulating Message Header. The meaning of an address is defined by the protocol using this specification. 🏠
Address Prefix - An address plus a prefix length, with the prefix length being a number of address bits measured from the left/most significant end of the address. 🛣️
Address Object - Either an address, or an address prefix, as specified in an Address Block in this specification. 🎯
TLV - A type-length-value structure. This is a generic way in which an attribute can be represented and correctly parsed without the parser having to understand the attribute. 🫶
3. Applicability Statement ✨
okay so this section is basically the vibe check for the whole spec 💅 It's a generic packet format made for MANET routing protocols, and it's inspired by and extended from the one OLSR uses [RFC3626]. ngl that's a very solid origin story 🦋
MANETs are usually (not always, but usually) running over wireless interfaces with limited to moderate capacity 📶 So they're way less chill about wasted octets than most wired networks are. This spec is a tradeoff between competing attributes: efficiency, extensibility, and ease of use. It's giving balance ⚖️
Efficiency comes from making packets smaller and from letting multiple disjoint messages live in one packet 🍓 Smaller packets mostly come from address aggregation, plus optional Packet Header and Message Header fields, plus optional fields in Address Blocks and TLVs. Multi-message packets mean fewer packets overall, and every packet can cost a lot of bandwidth from the transport, network, and lower layers, so fewer is literally better 🙌
Extensibility comes in two flavours. External extensibility means you can add Packet TLVs and define new Message Types 🧚 Internal extensibility means you can add Message TLVs and Address Block TLVs to existing messages ✨ Protocols can define new TLV Types (and therefore new contents for their Value fields) and new Message Types, see Section 6.1. They can also reuse TLV Type definitions from other protocols that use this spec too. Main character energy, honestly 👑
This spec is meant to be expressive and flexible enough for different classes of MANET routing protocols, like proactive, reactive, and hybrid ones, plus their extensions 🌈 Having one common packet and message format, and one common way to represent IP addresses and their attributes, means generic parsing code can be built no matter what algorithm the routing protocol uses. Iconic 🫶
All addresses within a message are assumed to be the same size, and that size is specified in the Message Header 📏 If you're mixing IPv6 and IPv4 addresses, IPv4 addresses can be represented as IPv4-mapped IPv6 addresses, as specified in [RFC4291] 🦋
The messages here are designed to carry MANET routing protocol signaling between MANET routers 📡 The spec includes elements that support scope-limited flooding, and it's also usable for point-to-point delivery of that signaling across a multi-hop network. Packets may be unicast or multicast, and they may use any appropriate transport protocol or none at all 💖
A MANET routing protocol using this message format can constrain the syntax it employs. For example, it can require a specific set of Message Header fields. Protocols with those restrictions don't need to be able to parse every possible message structure this document defines, but they must be coherent in generating and receiving the messages they define 🎀 If a protocol specifies which elements are included, then direct indexing of the appropriate fields is possible, depending on the syntax restrictions that protocol imposes. Those protocols might have more limited extensibility, and that's okay bestie 🥹
4. Protocol Overview and Functioning
ok this one's short and sweet 🍬 This spec does not describe a protocol. It describes a packet format, which any mobile ad hoc network routing protocol may use 🧚
5. Syntactical Specification
this section is the normative one, so it's where the actual rules live 📜 It gives the syntactical spec of a packet, represented by the element <packet> and all the elements it's built from. The notation is the one from Section 2.1.
Graphical illustrations of the layout of the specified elements are in Appendix D, and a graphical illustration of a complete example (a packet with a message that has Address Blocks and TLVs) is in Appendix E 🖼️
This format uses network byte order, as indicated in Section 2.1 🔢
5.1. Packets
<packet> is defined by:
<packet> := <pkt-header>
<message>*where <message> is as defined in Section 5.2. Successful parsing ends when all octets of the packet (as defined by the datagram containing the packet) have been used ✅
<pkt-header> is defined by:
<pkt-header> := <version>
<pkt-flags>
<pkt-seq-num>?
<tlv-block>?where:
<version>is a 4-bit unsigned integer field. It specifies the version of the specification that the packet and the messages inside it are built on. This document specifies version 0 🔖<pkt-flags>is a 4-bit field that specifies how to interpret the rest of the Packet Header 🚩- bit 0 (
phasseqnum): If cleared ('0'), then<pkt-seq-num>is not included in the<pkt-header>. If set ('1'), then<pkt-seq-num>is included in the<pkt-header>. - bit 1 (
phastlv): If cleared ('0'), then<tlv-block>is not included in the<pkt-header>. If set ('1'), then<tlv-block>is included in the<pkt-header>. - bits 2-3: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception. 🙈
- bit 0 (
<pkt-seq-num>is omitted if thephasseqnumflag is cleared ('0'). Otherwise, it's a 16-bit unsigned integer field that specifies a Packet Sequence Number 🔢<tlv-block>is omitted if thephastlvflag is cleared ('0'), and is otherwise as defined in Section 5.4 🎀
It is assumed that the network layer can deliver the exact payload length, so the packet doesn't have to carry its own length. No extra bytes wasted, periodt 💅
5.2. Messages
Packets may contain one or more messages, in addition to the Packet Header 📨 A message contains:
- A Message Header.
- A Message TLV Block that contains zero or more TLVs, associated with the whole message.
- Zero or more Address Blocks, each containing one or more address objects.
- An Address Block TLV Block, containing zero or more TLVs, that follows each Address Block and lets you associate addresses with extra attributes 🏷️
<message> is defined by:
<message> := <msg-header>
<tlv-block>
(<addr-block><tlv-block>)*
<msg-header> := <msg-type>
<msg-flags>
<msg-addr-length>
<msg-size>
<msg-orig-addr>?
<msg-hop-limit>?
<msg-hop-count>?
<msg-seq-num>?where:
<tlv-block>is as defined in Section 5.4.<addr-block>is as defined in Section 5.3.<msg-type>is an 8-bit unsigned integer field that specifies the type of the message 🧾<msg-flags>is a 4-bit field that specifies how to interpret the rest of the Message Header 🚩- bit 0 (
mhasorig): If cleared ('0'), then<msg-orig-addr>is not included in the<msg-header>. If set ('1'), then<msg-orig-addr>is included in the<msg-header>. - bit 1 (
mhashoplimit): If cleared ('0'), then<msg-hop-limit>is not included in the<msg-header>. If set ('1'), then<msg-hop-limit>is included in the<msg-header>. - bit 2 (
mhashopcount): If cleared ('0'), then<msg-hop-count>is not included in the<msg-header>. If set ('1'), then<msg-hop-count>is included in the<msg-header>. - bit 3 (
mhasseqnum): If cleared ('0'), then<msg-seq-num>is not included in the<msg-header>. If set ('1'), then<msg-seq-num>is included in the<msg-header>.
- bit 0 (
<msg-addr-length>is a 4-bit unsigned integer field that encodes the length of all addresses in this message (<msg-orig-addr>as well as each address in Address Blocks, as defined in Section 5.3). It's encoded as follows:
<msg-addr-length> = the length of an address in octets - 1So <msg-addr-length> is 3 for IPv4 addresses, or 15 for IPv6 addresses 🌸
address-length is a variable whose value is the length of an address in octets. It's calculated as follows:
address-length = <msg-addr-length> + 1<msg-size>is a 16-bit unsigned integer field that specifies the number of octets making up the<message>, including the<msg-header>📏<msg-orig-addr>is omitted if themhasorigflag is cleared ('0'). Otherwise, it's an identifier with a length equal toaddress-length, which can serve to uniquely identify the MANET router that originated the message 🪪<msg-hop-limit>is omitted if themhashoplimitflag is cleared ('0'). Otherwise, it's an 8-bit unsigned integer field that can contain the maximum number of hops the message should be further transmitted ⏳<msg-hop-count>is omitted if themhashopcountflag is cleared ('0'). Otherwise, it's an 8-bit unsigned integer field that can contain the number of hops the message has traveled 🦶<msg-seq-num>is omitted if themhasseqnumflag is cleared ('0'). Otherwise, it's a 16-bit unsigned integer field that can contain a sequence number, generated by the message's originator MANET router 🔁
5.3. Address Blocks ✨
okay bestie, Address Blocks are where the addresses get packed up together 🎀 An Address Block can hold one or more addresses, and every one of them is address-length octets long. That length comes from <msg-addr-length> in the <msg-header> of the message holding the block 💅 It can also carry prefix lengths that apply to all the addresses in the block, if that fits the situation 🦋 So an Address Block can specify either addresses or address prefixes.
A protocol may say that an address with a maximum prefix length (equal to the address length in bits, i.e., 8 * address-length) counts as an address, not an address prefix. That lets one Address Block hold a mix of addresses and address prefixes 🌈 This spec uses the term "address object" to cover both. Also, an address object in an Address Block always includes the prefix length, if there is one 🧚
An address is written as a sequence of address-length octets in the form Head:Mid:Tail. Head, Mid, and Tail have no semantics of their own. The split only exists so addresses can be aggregated, since they often share parts (like common prefixes, or several IPv6 addresses on the same interface) 🫶 An Address Block holds an ordered set of addresses that all share the same Head and the same Tail, but each one has its own Mid. Head and Tail can also be empty, so address objects without common Heads or common Tails are fine too 💜 Detailed examples of Address Blocks are in Appendix C.1.
An Address Block can specify address prefixes:
- with a single prefix length for all address prefixes, or
- with a prefix length for each address prefix.
<address-block> is defined by:
<address-block> := <num-addr>
<addr-flags>
(<head-length><head>?)?
(<tail-length><tail>?)?
<mid>*
<prefix-length>*where:
<num-addr>is an 8-bit unsigned integer field with the number of addresses in the Address Block, which MUST NOT be zero. 🙈<addr-flags>is an 8-bit field that tells you how to read the rest of the Address Block 🍓- bit 0 (
ahashead): If cleared ('0'), then<head-length>and<head>are not included in the<address-block>. If set ('1'), then<head-length>is included, and<head>is included unless<head-length>is zero. - bit 1 (
ahasfulltail) and bit 2 (ahaszerotail): These are interpreted according to Table 1. A combination not shown in that table MUST NOT be used. 💀 - bit 3 (
ahassingleprelen) and bit 4 (ahasmultiprelen): These are interpreted according to Table 2. A combination not shown in that table MUST NOT be used. 💀 - bits 5-7: Are RESERVED and SHOULD each be cleared (
'0') on transmission and SHOULD be ignored on reception. 🌸
- bit 0 (
Here's Table 1 (the flag combos for the tail) 👑
+--------------+--------------+---------------+---------------------+
| ahasfulltail | ahaszerotail | <tail-length> | <tail> |
+--------------+--------------+---------------+---------------------+
| 0 | 0 | not included | not included |
| 1 | 0 | included | included unless |
| | | | <tail-length> is |
| | | | zero |
| 0 | 1 | included | not included |
+--------------+--------------+---------------+---------------------+Table 1: Interpretation of the ahasfulltail and ahaszerotail flags
And Table 2 (the prefix-length combos) 🦋
+------------+-----------+------------------+-----------------------+
| ahassingle | ahasmulti | number of | prefix length of the |
| prelen | prelen | <prefix-length> | nth address prefix, |
| | | fields | in bits |
+------------+-----------+------------------+-----------------------+
| 0 | 0 | 0 | 8 * address-length |
| 1 | 0 | 1 | <prefix-length> |
| 0 | 1 | <num-addr> | nth <prefix-length> |
+------------+-----------+------------------+-----------------------+Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen flags
<head-length>, if present, is an 8-bit unsigned integer field with the number of octets in the Head of all the addresses in the Address Block. So each<head>element included is<head-length>octets long. 🎀head-lengthis a variable, defined to equal<head-length>if present, or 0 otherwise.<head>is omitted ifhead-lengthis equal to 0. Otherwise, it's a field of thehead-lengthleftmost octets that all the addresses in the Address Block have in common. ✨<tail-length>, if present, is an 8-bit unsigned integer field with the number of octets in the Tail of all the addresses in the Address Block. So each<tail>element included is<tail-length>octets long. 💅tail-lengthis a variable, defined to equal<tail-length>if present, or 0 otherwise.<tail>is omitted iftail-lengthis equal to 0, or if theahaszerotailflag is set ('1'). Otherwise, it's a field of thetail-lengthrightmost octets that all the addresses in the Address Block have in common. If theahaszerotailflag is set ('1'), then thetail-lengthrightmost octets of all the addresses in the Address Block are 0. 🌈mid-lengthis a variable that MUST be non-negative, defined by:
mid-length := address-length - head-length - tail-lengthi.e., each <mid> element included is mid-length octets long. 🧚
<mid>is omitted ifmid-lengthis equal to 0. Otherwise, each<mid>is a field ofmid-lengthoctets, representing the Mid of the matching address in the Address Block. When it's not omitted, an Address Block contains exactly<num-addr><mid>fields. 🫶<prefix-length>is an 8-bit unsigned integer field with the length, in bits, of an address prefix. If theahassingleprelenflag is set ('1'), then one<prefix-length>field is included, holding the prefix length of all addresses in the Address Block. If theahasmultiprelenflag is set ('1'), then<num-addr><prefix-length>fields are included, each holding the prefix length of the matching address prefix in the Address Block (in the same order). Otherwise, no<prefix-length>fields are present, and each address object can be considered to have a prefix length equal to8 * address-lengthbits. 💜 The Address Block is malformed if any<prefix-length>element has a value greater than8 * address-length. 🙈
5.4. TLVs and TLV Blocks
okay so TLVs are how you attach an arbitrary attribute to a message, to a packet, or to a single address or a contiguous set of addresses in an Address Block 🦋 The attribute (its value) is made of an integer number of consecutive octets. Different attributes have different types, and any attribute you don't recognise while parsing can just be skipped 💅
TLVs get grouped into TLV Blocks. All the TLVs in one TLV Block attach their attributes to either the packet (for the TLV Block in the Packet Header), the message (for the TLV Block right after the Message Header), or the addresses in the Address Block right before it 👑 A TLV Block right after an Address Block can attach attributes to one address, a range of addresses, or all the addresses in that block. When a TLV covers more than one address, it can include one value for all of them, or one value per address 🌸 Detailed examples of TLVs are in Appendix C.2.
A TLV Block is defined by:
<tlv-block> := <tlvs-length>
<tlv>*where:
<tlvs-length>is a 16-bit unsigned integer field with the total number of octets in all the immediately following<tlv>elements. The<tlvs-length>field itself is not included. 🍓<tlv>is as defined in Section 5.4.1. ✨
5.4.1. TLVs ✨
okay so there are three kinds of TLV, and each one gets written as a <tlv> element 💖
- A Packet TLV 🎀, which goes in the Packet TLV Block inside a Packet Header.
- A Message TLV 🦋, which goes in the Message TLV Block in a message, before any Address Blocks.
- An Address Block TLV 🌸, which goes in an Address Block TLV Block that comes after an Address Block. It can apply to:
- all address objects in the Address Block, or
- any continuous sequence of address objects in the Address Block, or
- a single address object in the Address Block.
here's how <tlv> is built 🧚
<tlv> := <tlv-type>
<tlv-flags>
<tlv-type-ext>?
(<index-start><index-stop>?)?
(<length><value>?)?and here's what each piece means 👑
<tlv-type>is an 8-bit unsigned integer field. It says what type the TLV is, and that's specific to the kind of TLV (Packet TLV, Message TLV, or Address Block TLV).<tlv-flags>is an 8-bit field that tells you how to read the rest of the TLV 🔥- bit 0 (
thastypeext): if it's cleared ('0'), then<tlv-type-ext>is not included in the<tlv>. If it's set ('1'), then<tlv-type-ext>is included. - bit 1 (
thassingleindex) and bit 2 (thasmultiindex): these are interpreted according to Table 3. A combination that isn't shown in that table MUST NOT be used. Both of these flags MUST be cleared ('0') in Packet TLVs and Message TLVs. - bit 3 (
thasvalue) and bit 4 (thasextlen): these are interpreted according to Table 4. A combination that isn't shown in that table MUST NOT be used. - bit 5 (
tismultivalue): this flag decides how the<value>field gets interpreted, which is explained below. This flag MUST be cleared ('0') in Packet TLVs and Message TLVs, if thethasmultiindexflag is cleared ('0'), or if thethasvalueflag is cleared ('0'). - bits 6-7: these are RESERVED and SHOULD each be cleared ('0') on transmission, and SHOULD be ignored on reception.
- bit 0 (
here's Table 3 for the index flags 🦋
+-----------------+----------------+---------------+--------------+
| thassingleindex | thasmultiindex | <index-start> | <index-stop> |
+-----------------+----------------+---------------+--------------+
| 0 | 0 | not included | not included |
| 1 | 0 | included | not included |
| 0 | 1 | included | included |
+-----------------+----------------+---------------+--------------+
Table 3: Interpretation of the
thassingleindex and thasmultiindex flagsand Table 4 for the value and length flags 💅
+-----------+------------+--------------+---------------------------+
| thasvalue | thasextlen | <length> | <value> |
+-----------+------------+--------------+---------------------------+
| 0 | 0 | not included | not included |
| 1 | 0 | 8 bits | included unless <length> |
| | | | is zero |
| 1 | 1 | 16 bits | included unless <length> |
| | | | is zero |
+-----------+------------+--------------+---------------------------+
Table 4: Interpretation of the thasvalue and thasextlen flagsmore fields, more vibes 🌈
<tlv-type-ext>is an 8-bit unsigned integer field. It extends the TLV Type, and it's specific to both the TLV Type and the kind of TLV (Packet TLV, Message TLV, or Address Block TLV).tlv-type-extis a variable. It equals<tlv-type-ext>if that's present, and 0 otherwise.tlv-fulltypeis a variable, defined by:
tlv-fulltype := 256 * <tlv-type> + tlv-type-ext<index-start>and<index-stop>, when they're present (and only in an Address Block TLV), are each an 8-bit unsigned integer field.index-startandindex-stopare variables, and they get defined using Table 5. The variableend-indexis defined like this 🧁- For Message TLVs and Packet TLVs:
end-index := 0- For Address Block TLVs:
end-index := <num-addr> - 1an Address Block TLV applies to the address objects from position index-start to position index-stop (inclusive) in the Address Block. The first address object has position zero 🫶
Table 5 is the cheat sheet for those two variables 📝
+-----------------+----------------+----------------+---------------+
| thassingleindex | thasmultiindex | index-start := | index-stop := |
+-----------------+----------------+----------------+---------------+
| 0 | 0 | 0 | end-index |
| 1 | 0 | <index-start> | <index-start> |
| 0 | 1 | <index-start> | <index-stop> |
+-----------------+----------------+----------------+---------------+
Table 5: Interpretation of the
thassingleindex and thasmultiindex flagsnumber-valuesis a variable, defined by:
number-values := index-stop - index-start + 1<length>is either omitted, or it's an 8-bit or 16-bit unsigned integer field, depending on Table 4. If thetismultivalueflag is set ('1'), then<length>MUST be an integral multiple ofnumber-values, and the variablesingle-lengthis defined by:
single-length := <length> / number-valuesIf the tismultivalue flag is cleared ('0'), then the variable single-length is defined by:
single-length := <length><value>, if it's present (see Table 4), is a field of length<length>octets. In an Address Block TLV,<value>is associated with the address objects from positionsindex-starttoindex-stop, inclusive. If thetismultivalueflag is cleared ('0'), then the whole of this field is associated with each of the indicated address objects. If thetismultivalueflag is set ('1'), then this field is divided equally intonumber-valuesfields, each of lengthsingle-lengthoctets, and these get associated, in order, with the indicated address objects 🌸
5.4.2. TLV Usage 💜
okay so a TLV links an attribute to a packet, a message, or one or more consecutive address objects in an Address Block 🦋 The way that attribute gets interpreted and processed, plus how different attributes tied to the same entity relate to each other (including the order they're processed in), MUST be defined by any protocol that uses this specification.
any protocol using this specification MUST define appropriate behaviors for when this associated information is inconsistent 💀 That's especially true when two TLVs of the same type but with different values apply to the same entity (packet, message, or address) and that combo doesn't actually mean anything. The protocol MUST also specify an appropriate processing order for TLVs associated with a given entity ✨
5.5. Malformed Elements 🙈
an element is malformed if it can't be parsed according to its syntactical specification. That includes the case where there aren't enough octets available. If the malformed element is in the Packet Header, then the packet MUST be silently discarded, and the contained messages MUST NOT be processed and MUST NOT be forwarded. If the malformed element is contained in a message (so, in the Message TLV Block, an Address Block, or an Address Block TLV Block), then that message MUST be silently discarded. It MUST NOT be processed and MUST NOT be forwarded 😭
6. IANA Considerations 🌈
this document introduces four namespaces that have been registered: Message Types, Packet TLV Types, Message TLV Types, and Address Block TLV Types 🍓 This section sets up IANA registries for these namespaces, and it gives guidance to the Internet Assigned Numbers Authority about registrations in them.
the following terms are used with the meanings defined in [BCP26]: "Namespace", "Assigned Value", "Registration", "Unassigned", "Reserved", "Hierarchical Allocation", and "Designated Expert" 🎀
the following policies are used with the meanings defined in [BCP26]: "Private Use", "Expert Review", and "Standards Action" 💅
6.1. Expert Review: Evaluation Guidelines ✨
okay so when a registration needs Expert Review, the Designated Expert SHOULD keep these general recommendations in mind 💅
- The whole point of these registries is to support Standard and Experimental MANET routing and related protocols and extensions to those protocols 🦋
- The plan is that every registration comes with a published RFC 📜
- So registration can happen before the RFC is approved for publication, the Designated Expert can approve the registration once it seems clear that an RFC is expected to be published 🫶
- The Designated Expert will post a request to the MANET WG mailing list, or to a successor thereto as designated by the Area Director, asking for comments and reviews. This request will include a reference to the Internet-Draft requesting the registration 💌
- Before 30 days have passed, the Designated Expert will either approve or deny the registration request. They'll also publish a note of the decision to the MANET WG mailing list or its successor, and inform IANA and the IESG 🔥. A denial note MUST be justified by an explanation, and where it's possible, suggestions for how the request can be modified so it becomes acceptable SHOULD be provided 🙈
For the registry for Message Types, the following guidelines apply:
- Registering a Message Type creates two registries: one for Message-Type-specific Message TLVs and one for Message-Type-specific Address Block TLVs 🌸. The document that requests the registration of the Message Type MUST indicate how these Message-Type-specific TLV Types are to be allocated, from any options in [BCP26], and any initial allocations. The Designated Expert SHOULD take the allocation policies specified for these registries into consideration when reviewing the Message Type allocation request 🧚
For the registries for Packet TLV Types, Message TLV Types, and Address Block TLV Types, the following guidelines apply:
- These are Hierarchical Allocations, so allocating a type creates a registry for the extended types that belong to it 🌈. The document that requests the registration of the type MUST indicate how these extended types are to be allocated, from any options in [BCP26], and any initial allocations. Normally this allocation should also undergo Expert Review, though some type extensions might be allocated as Reserved, Experimental, and/or Private 🎀
- The request for a TLV Type MUST include the specification of the permitted size, syntax of any internal structure, and meaning, of the Value field (if any) of the TLV 📏
For the registries for Message TLV Types and Address Block TLV Types, the following additional guidelines apply:
- TLV Type values 0-127 are common for all Message Types 🌍. TLVs that get registrations from the 0-127 interval SHOULD be modular in design so they can be reused among protocols 🧩
- TLV Type values 128-223 are Message-Type-specific, which means they only matter in the context of the Message Type that contains them 💜. Registering a TLV Type value within the 128-223 interval requires that a registry in that interval exists for a specific Message Type value (see Section 6.2.1), and registrations are made according to the allocation policies specified for those Message-Type-specific registries 📚. Message-Type-specific TLV Types SHOULD be registered for TLVs that the Designated Expert deems too Message-Type-specific for a 0-127 value 🍓. Multiple different TLV definitions MAY be assigned the same TLV Type value within the 128-223 interval, as long as they're associated with different Message-Type-specific TLV Type registries 🦄. Where possible, existing global TLV definitions and modular global TLV definitions for registration in the 0-127 range SHOULD be used 👑
6.2. Message Types
A new registry for Message Types has been created, with initial assignments and allocation policies as specified in Table 6.
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+
Table 6: Message Types6.2.1. Message-Type-Specific TLV Registry Creation
When a Message Type is registered, registries MUST be specified for both Message-Type-specific Message TLVs (Table 8) and Message-Type-specific Address Block TLVs (Table 10). A document that creates a Message-Type-specific TLV registry MUST also specify the mechanism by which Message-Type-specific TLV Types are allocated, from among those in [BCP26] 🔐.
6.3. Packet TLV Types
A new registry for Packet TLV Types has been created, with initial assignments and allocation policies as specified in Table 7 🌟.
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+
Table 7: Packet TLV Types6.3.1. Packet TLV Type Extension Registry Creation
When a Packet TLV Type is registered, a new registry for type extensions of that type must be created. A document that defines a Packet TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26] 🧠.
6.4. Message TLV Types
A new registry for Message-Type-independent Message TLV Types has been created, with initial assignments and allocation policies as specified in Table 8 💖.
+---------+-----------------------+-----------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------+-----------------------+
| 0-127 | Unassigned | Expert Review |
| 128-223 | Message-Type-specific | Reserved, see Table 9 |
| 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+-----------------------+
Table 8: Message TLV TypesMessage TLV Types 128-223 are reserved for Message-Type-specific Message TLVs. A new registry is created for them when a Message Type is registered, with initial assignments and allocation policies as specified in Table 9 🎀.
+---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message-Type-specific | See Below |
| 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+
Table 9: Message-Type-specific Message TLV TypesAllocation policies for Message-Type-specific Message TLV Types MUST be specified when creating the registry associated with the containing Message Type, see Section 6.2.1 🗂️.
6.4.1. Message TLV Type Extension Registry Creation
If a Message TLV Type is registered, a new registry for type extensions of that type must be created. A document that defines a Message TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26] 🌷.
6.5. Address Block TLV Types
A new registry for Message-Type-independent Address Block TLV Types has been created, with initial assignments and allocation policies as specified in Table 10 🦋.
+---------+-----------------------+------------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------+------------------------+
| 0-127 | Unassigned | Expert Review |
| 128-223 | Message-Type-specific | Reserved, see Table 11 |
| 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+------------------------+
Table 10: Address Block TLV TypesAddress Block TLV Types 128-223 are reserved for Message-Type-specific Address Block TLVs. A new registry is created for them when a Message Type is registered, with initial assignments and allocation policies as specified in Table 11 ✨.
+---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message-Type-specific | See Below |
| 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+
Table 11: Message-Type-specific Address Block TLV TypesAllocation policies for Message-Type-specific Address Block TLV Types MUST be specified when creating the registry associated with the containing Message Type, see Section 6.2.1 🌸.
6.5.1. Address Block TLV Type Extension Registry Creation
When an Address Block TLV Type is registered, a new registry for type extensions of that type must be created. A document that defines a Message TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26] 🧁.
7. Security Considerations 🔒
This specification does not describe a protocol; it describes a packet format. As such, it does not specify any security considerations. Those are matters for a protocol using this specification 🙈. However, some security mechanisms are enabled by this specification and may form part of a protocol using it. Mechanisms that may form part of an authentication and integrity approach in a protocol using this specification are described in Section 7.1. Mechanisms that may form part of a confidentiality approach in a protocol using this specification are described in Section 7.2. There is, however, no requirement that a protocol using this specification should use either 💀.
7.1. Authentication and Integrity Suggestions ✨
okay so these authentication and integrity tips are based on how Appendix B expects this thing to be used 🫶 basically:
- Messages are designed to be carriers of protocol information and MAY, at each hop, be forwarded and/or processed by the protocol using this specification. 💅
- Packets are designed to carry a number of messages between neighboring MANET routers in a single transmission and over a single logical hop. 🚀
Consequently:
- For forwarded messages where the message is unchanged by forwarding MANET routers, end-to-end authentication and integrity MAY be implemented, between MANET routers with an existing security association, by including a suitable Message TLV containing a cryptographic signature in the message. Since
<msg-hop-count>and<msg-hop-limit>are the only fields that should be modified when such a message is forwarded in this manner, this signature can be calculated based on the entire message, including the Message Header, with the<msg-hop-count>and<msg-hop-limit>fields set to 0, if present. 🔐✨ - Hop-by-hop packet level authentication and integrity MAY be implemented, between MANET routers with an existing security association, by including a suitable Packet TLV containing a cryptographic signature to the packet. Since packets are received as transmitted, this signature can be calculated based on the entire packet or on parts thereof as appropriate. 🦋
7.2. Confidentiality Suggestions 🎀
okay this one is kinda the spicy part 🌶️ this specification does not explicitly turn on packet or message confidentiality. If you need it, it would normally be handled hop-by-hop, either by link-layer mechanisms or at the IP layer using [RFC4301], and it would only cover a single packet. 🔒
It is possible, however, for a protocol using this specification to protect the confidentiality of information included in a Packet, Message, or Address Block TLV. The trick is to specify that the Value field of that TLV Type gets encrypted, and to also spell out the encryption mechanism. Main character energy 👑
In an extreme case, all information can be encrypted by defining either:
- A packet, consisting of only a Packet Header (with no messages) and containing a Packet TLV, where the Packet TLV Type indicates that its Value field contains one or more encrypted messages. Upon receipt, and once this Packet TLV is successfully decrypted, these messages may then be parsed according to this specification and processed according to the protocol using this specification. 🧚
- A message, consisting of only a Message Header and a single Message TLV, where the Message TLV Type indicates that its Value field contains an encrypted version of the message's remaining Message TLVs, Address Blocks, and Address Block TLVs. Upon receipt, and once this Message TLV is successfully decrypted, the complete message may then be parsed according to this specification and processed according to the protocol using this specification. 🍓
In either case, the protocol MUST define the encrypted TLV Type, as well as the format of the encrypted data block contained in the Value field of the TLV. This part is NOT optional bestie 🙈
8. Contributors 🌈
This specification is the result of the joint efforts of the following contributors from the OLSRv2 Design Team, listed alphabetically: 💜
- Cedric Adjih, INRIA, France,
<Cedric.Adjih@inria.fr> - Emmanuel Baccelli, INRIA, France,
<Emmanuel.Baccelli@inria.fr> - Thomas Heide Clausen, LIX, Ecole Polytechnique, France,
<T.Clausen@computer.org> - Justin W. Dean, NRL, USA,
<jdean@itd.nrl.navy.mil> - Christopher Dearlove, BAE Systems, UK,
<chris.dearlove@baesystems.com> - Satoh Hiroki, Hitachi SDL, Japan,
<hiroki.satoh.yj@hitachi.com> - Philippe Jacquet, INRIA, France,
<Philippe.Jacquet@inria.fr> - Monden Kazuya, Hitachi SDL, Japan,
<kazuya.monden.vw@hitachi.com>
9. Acknowledgments 🫶
The authors would like to acknowledge the team behind OLSR [RFC3626], including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot (both at INRIA, France), and Amir Qayyum (Center for Advanced Research in Engineering, Pakistan) for their contributions. Elwyn Davies (Folly Consulting, UK), Lars Eggert (Nokia, Finland), Chris Newman (Sun Microsystems, USA), Tim Polk (NIST, USA), and Magnus Westerlund (Ericsson, Sweden) all provided detailed reviews and insightful comments. Thank you all, you're literally the reason this works ✨
The authors would also like to gratefully acknowledge the following people for intense technical discussions, early reviews, and comments on the specification and its components (listed alphabetically): 🌸
- Brian Adamson (NRL)
- Teco Boot (Infinity Networks)
- Florent Brunneau (LIX)
- Ian Chakeres (CenGen)
- Alan Cullen (BAE Systems)
- Ulrich Herberg (LIX)
- Joe Macker (NRL)
- Yasunori Owada (Niigata University)
- Charlie E. Perkins (WiChorus)
- Henning Rogge (FGAN)
- Andreas Schjonhaug (LIX)
and the entire IETF MANET working group. 💖
10. References 📚
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008.
[SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC
1/SC22/WG15, "Single UNIX Specification, Version 3,
2004 Edition", April 2004.10.2. Informative References
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The
Protocols", 1994.Appendix A. Multiplexing and Demultiplexing 🦋
The packet and message format specified in this document is designed to allow zero or more messages to be contained within a single packet. Such messages may be from the same or different protocols. Thus, a multiplexing and demultiplexing process MUST be present. 🧩
Multiplexing messages on a given MANET router into a single packet, rather than having each message generate its own packet, reduces the total number of octets and the number of packets transmitted by that MANET router. Big efficiency energy 🔥
The multiplexing and demultiplexing process running on a given UDP port or IP protocol number, and its associated protocols, MUST:
- For each Message Type, a protocol -- unless specified otherwise, the one making the IANA reservation for that Message Type -- MUST be designated as the "owner" of that Message Type. 👑
- The Packet Header fields, including the Packet TLV Block, are used by the multiplexing and demultiplexing process, which MAY make such information available for use in its protocol instances. 🎀
- The
<pkt-seq-num>field, if present, contains a sequence number that is incremented by 1 for each packet generated by a node. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way. 🔄 - Incoming messages MUST be either silently discarded or MUST be delivered to the instance of the protocol that owns the associated Message Type. Incoming messages SHOULD NOT be delivered to any other protocol instances and SHOULD NOT be delivered to more than one protocol instance. 🙅♀️
- Outgoing messages of a given type MUST be generated only by the protocol instance that owns that Message Type and be delivered to the multiplexing and demultiplexing process. 💌
- If two protocols both wish to use the same Message Type, then this interaction SHOULD be specified by the protocol that is the designated owner of that Message Type. 🫶
Appendix B. Intended Usage 🌷
This appendix describes the intended usage of Message Header fields, including their content and use. Alternative uses of this specification are permitted. 🌈
The message format specified in this document is designed to carry MANET routing protocol signaling between MANET routers and to support scope-limited flooding as well as point-to-point delivery. Messages are designed to be able to be forwarded over one or more logical hops, in a new packet for each logical hop. Each logical hop may consist of one or more IP hops. 🛰️
Specifically, scope-limited flooding is supported for messages when:
- The
<msg-orig-addr>field, if present, contains the unique identifier of the MANET router that originated the message. 🆔 - The
<msg-seq-num>field, if present, contains a sequence number that starts at 0 when the first message of a given type is generated by the originator node, and that is incremented by 1 for each message generated of that type. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way. 🔢 - If the
<msg-orig-addr>and<msg-seq-num>fields are both present, then the Message Header provides for duplicate suppression, using the identifier consisting of the message's<msg-orig-addr>,<msg-seq-num>, and<msg-type>. These serve to uniquely identify the message in the MANET within the time period until<msg-seq-num>is repeated, i.e., wraps around to a matching value. 🕵️♀️ <msg-hop-limit>field, if present, contains the number of hops on which the packet is allowed to travel before being discarded by a MANET router. The<msg-hop-limit>is set by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should decrease the<msg-hop-limit>by 1, and the message should be discarded when<msg-hop-limit>reaches 0. ⏳<msg-hop-count>field, if present, contains the number of hops on which the packet has traveled across the MANET. The<msg-hop-count>is set to 0 by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should increase<msg-hop-count>by 1 and should discard the message when<msg-hop-count>reaches 255. 🧮- If the
<msg-hop-limit>and<msg-hop-count>fields are both present, then the Message Header provides the information to make forwarding decisions for scope-limited flooding. This may be by any appropriate flooding mechanism specified by a protocol using this specification. 🌊
Appendix C. Examples 🍭
This appendix contains some examples of parts of this specification. ✨
C.1. Address Block Examples 🎀
Okay bestie, these examples show how some combos of addresses can be packed super efficiently into Address Blocks ✨. Everything here is for IPv4, so address-length is 4. The letters a, b, c and so on stand for distinct, non-zero octet values 💖.
Quick note: you're allowed to use a less efficient representation 🙈. In that version the ahashead and ahasfulltail flags are cleared ('0'), so head-length = 0, tail-length = 0, and mid-length = address-length. With no address prefixes, the Address Block is just the number of addresses, <addr-flags> set to 0, and a list of the unaggregated addresses. This is the most efficient way to store a single address, and the only way to fit something like a.b.c.d and e.f.g.h into one Address Block 💅.
Examples:
- To include a.b.c.d, a.b.e.f, and a.b.g.h:
- head-length = 2;
- tail-length = 0;
- mid-length = 2;
<addr-flags>has ahashead set (value 128);<tail-length>and<tail>are omitted.
The Address Block is then 3 128 2 a b c d e f g h (11 octets) 🦋.
- To include a.b.c.g and d.e.f.g:
- head-length = 0;
- tail-length = 1;
- mid-length = 3;
<addr-flags>has ahasfulltail set (value 64);<head-length>and<head>are omitted.
The Address Block is then 2 64 1 g a b c d e f (10 octets) 🌸.
- To include a.b.d.e and a.c.d.e:
- head-length = 1;
- tail-length = 2;
- mid-length = 1;
<addr-flags>has ahashead and ahasfulltail set (value 192).
The Address Block is then 2 192 1 a 2 d e b c (9 octets) 🫶.
- To include a.b.0.0, a.c.0.0, and a.d.0.0:
- head-length = 1;
- tail-length = 2;
- mid-length = 1;
<addr-flags>has ahashead and ahaszerotail set (value 160);<tail>is omitted.
The Address Block is then 3 160 1 a 2 b c d (8 octets) 🍓.
- To include a.b.0.0 and c.d.0.0:
- head-length = 0;
- tail-length = 2;
- mid-length = 2;
<addr-flags>has ahaszerotail set (value 32);<head>and<tail>are omitted.
The Address Block is then 2 32 2 a b c d (7 octets) 🧚.
- To include a.b.0.0/n and c.d.0.0/n:
- head-length = 0;
- tail-length = 2;
- mid-length = 2;
<addr-flags>has ahaszerotail and ahassingleprelen set (value 48);<head>and<tail>are omitted.
The Address Block is then 2 48 2 a b c d n (8 octets) 👑.
- To include a.b.0.0/n and c.d.0.0/m:
- head-length = 0;
- tail-length = 2;
- mid-length = 2;
<addr-flags>has ahaszerotail and ahasmultiprelen set (value 40);<head>and<tail>are omitted.
The Address Block is then 2 40 2 a b c d n m (9 octets) 💜.
C.2. TLV Examples ✨
Let's say we define an Address Block TLV with type EXAMPLE1 (no type extension) that has single-octet values per address. There are a bunch of ways that the values a, a, b, and c can be attached to the four addresses in the Address Block from before, where c is a default value that can be left out 🌈.
Examples:
- Using one multivalue TLV to cover all of the addresses:
<tlv-flags>has thasvalue and tismultivalue set (value 20);<index-start>and<index-stop>are omitted;<length>= 4 (single-length = 1).
The TLV is then EXAMPLE1 20 4 a a b c (7 octets) 💅.
- Using one multivalue TLV and leaving out the last address:
<tlv-flags>has thasmultiindex, thasvalue, and tismultivalue set (value 52);<index-start>= 0;<index-stop>= 2;<length>= 3 (single-length = 1).
The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets) 🦋.
- Using two single-value TLVs and leaving out the last address. First:
<tlv-flags>has thasmultiindex and thasvalue set (value 48);<index-start>= 0;<index-stop>= 1;<length>= 1;<value>= a.
The TLV is then EXAMPLE1 48 0 1 1 a (6 octets).
Second:
<tlv-flags>has thassingleindex and thasvalue set (value 80);<index-start>= 2;<index-stop>is omitted;<length>= 1;<value>= b.
The TLV is then EXAMPLE1 80 2 1 b (5 octets).
Total length of TLVs is 11 octets 🌸.
In this case, the first of these is the most efficient 🔥. In other cases, patterns like the others may be preferred. Regardless of efficiency, any of these may be used 🫶.
Let's say we define an Address Block TLV with type EXAMPLE2 (no type extension) that has no value and is meant to be attached to the second and third addresses in an Address Block. That can be done with one single TLV:
<tlv-flags>has thasmultiindex set (value 32);<index-start>= 1;<index-stop>= 2;<length>and<value>are omitted;- The TLV is then
EXAMPLE2 32 1 2(4 octets) 🧚.
Now, a Message TLV with type EXAMPLE3 (no type extension) that can take a Value field of any length 🎀. For such a TLV with 8 octets of data (a to h):
<tlv-flags>has thasvalue set (value 16);<index-start>and<index-stop>are omitted;<length>= 8.- The TLV is then
EXAMPLE3 16 8 a b c d e f g h(11 octets) 💖.
If, in this example, the number of data octets were 256 or greater, then <tlv-flags> would also have thasextlen set and have value 24. The length would need two octets (most significant first). The TLV length would be 4 + N octets, where N is the number of data octets (it can be 3 + N octets if N is 255 or less) 🙈.
Appendix D. Illustrations 🦋
This informative appendix illustrates the elements that are normatively specified in Section 5 💅.
Bits labeled Rsv should be cleared ('0'). Bits labeled M may be cleared ('0') or set ('1') ✨.
D.1. Packet 🎀
okay so this part shows off some possible options for the <packet> element 💅 they're told apart by the flags field in the first octet ✨ a packet can hold any number (zero or more) of messages 🦋 and you work out how many by reading until the packet runs out, using the packet length the network layer gives you 🫶
first up, flags 000000 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|Rsv| |
+-+-+-+-+-+-+-+-+ |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+next up, flags 000010 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|1|0|Rsv| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+now flags 000001 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|1|Rsv| |
+-+-+-+-+-+-+-+-+ |
| |
| Packet TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and the last packet option, flags 000011 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|1|1|Rsv| Packet Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Packet TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+D.2. Message 💖
okay bestie, this one shows the possible options for the <message> element 🍓 they're differentiated by their second octet, the flags one 💜 the length of the Message Body is worked out from the Message Size field, which is the combined length of all the fields shown 🌈 and the MAL field sets the length of all addresses (the Originator Address if it's present, plus every address in the Address Blocks) in octets, as one more than whatever value is in the field 🔥
first message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+next, the one with an Originator Address 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+now the one with a Hop Limit 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and both together, Originator Address plus Hop Limit 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+last but not least, the Hop Count one 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay bestie, this part is all pictures 🎀 Think of each diagram as a little outfit check for a message. Every row is 32 bits wide, so the ruler on top tells you where each bit lives 🧚
Here's the first one, look at that Message Type nibble go 👀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Next up, same vibe but a different flag combo 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay this one has an Originator Address AND Hop fields, it's giving full kit 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|1|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sequence Number era, let's go ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Now the Originator shows up to the party again 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Hop Limit plus Sequence Number, the duo is back 🍓
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Originator + Hop Limit + Sequence Number, the full combo 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|0|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Hop Count + Sequence Number, no Hop Limit this time 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Originator, Hop Count and Sequence Number all together 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|0|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Last of the batch, Hop Limit, Hop Count AND Sequence Number, the whole fit 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|1|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And the grand finale, every single field, Originator included 🌈✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |1|1|1|1| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+D.3. Message Body
okay so this section is all about the Message Body, which is basically the whole <message> element minus its first <msg-header> bit 🎀 It's giving one Message TLV Block (which can hold zero or more TLVs), and then it can have any number of Address Block and Address Block TLV Block pairs, including zero. Main character energy 👑
Here's the picture:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message TLV Block |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ |
| Address Block TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+D.4. Address Block
this one is the fun bit because it's a whole buffet of options 🍓 ✨ They're told apart by their second octet, which is the flags octet, so you check that and you know which layout you're looking at 💅
A couple of things to keep in mind: the number of Mid elements matches the number of addresses, except when mid-length is zero, in which case there are no Mid elements at all 🙈 And wherever a variable number of prefix length fields shows up, there's one for each address 🦋
Here are all the variations, one after another 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|0|0| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|0|0| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|0|0| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|0|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|1|0| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|1|0| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay bestie, here's the next batch of address block layouts 🦋 Each one is a different way the bits can be packed, so keep your eyes peeled for the flag bits 💅
Layout one:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+Layout two: ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|1|0| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Layout three: 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|1|0| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Layout four: 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|0|0|1| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Layout five: 🍓
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|0|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Layout six: 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|1|0|0|1| Rsv | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Layout seven: 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|1|0|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ |
: ... :
| +-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Layout eight: 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0|0|1|0|1| Rsv | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Layout nine: 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1|0|1|0|1| Rsv | Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+That's the whole batch! 🌈💖 The bit-level patterns are all there, so you can line them up against the field definitions and see how each layout gets packed 🫶
D.5. TLV Block 💖
okay so this bit shows what a <tlv-block> looks like 🎀 there can be zero or more TLVs in there, and all the TLVs together add up to the number in the Length field 🧮 it's giving tidy little packing vibes ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| TLV |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| TLV |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the diagram is giving full puzzle energy 🧩 the TLV boxes just keep stacking inside the block, and the Length field up top is the total for all of them 💅
D.6. TLV ✨
okay bestie, this section is basically the TLV hall of fame 💅 every option is told apart by its second (flags) octet 🦋. if there are no Index fields, it could be a Packet TLV, Message TLV, or Address Block TLV. but if there are one or two Index fields, then it must be an Address Block TLV 🧚 and the Length field tells you how long the Value field is, in octets. let's go through the looks one by one 🎀
Look 1, flags 0 0 0 0 0 0 with Rsv, so no Type Ext, no Index fields, no Length or Value:
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 |0|0|0|0|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Look 2, the high bit is on, so Type Ext joins the party 💜:
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 |1|0|0|0|0|0|Rsv| Type Ext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Look 3, the second bit is on, so Index Start shows up 🍓:
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 |0|1|0|0|0|0|Rsv| Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Look 4, Type Ext and Index Start are both in, which is giving double the fields 🌈:
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 |1|1|0|0|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Look 5, the third bit is on, so we get Index Start and Index Stop 🌸:
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 |0|0|1|0|0|0|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Look 6, the fullest index version. Type Ext, Index Start and Index Stop all show up, and Index Stop spills onto a second line 👑:
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 |1|0|1|0|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop |
+-+-+-+-+-+-+-+-+Look 7, the fourth bit with M, so Length and Value are in the mix ⭐:
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 |0|0|0|1|0|M|Rsv| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Look 8, Type Ext plus Length and Value, with the M bit in the flags 💖:
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 |1|0|0|1|0|M|Rsv| Type Ext | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Look 9, Index Start with Length and Value, and the Length field is a bit longer than usual 🎀:
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 |0|1|0|1|0|0|Rsv| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Look 10, Type Ext, Index Start, Length and Value all together 🦋:
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 |1|1|0|1|0|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Look 11, Index Start and Index Stop with Length and Value, plus the M bit 🍓:
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 |0|0|1|1|0|M|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Look 12, the full set of Type Ext, Index Start, Index Stop, Length and Value, with the M bit 🌈:
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 |1|0|1|1|0|M|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Look 13, the fifth bit is on, so Length and Value without any Index fields 🌸:
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 |0|0|0|0|1|M|Rsv| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Look 14, Type Ext with a Length that spills onto a second line, plus Value 💜:
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 |1|0|0|1|1|M|Rsv| Type Ext | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | |
+-+-+-+-+-+-+-+-+ |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Look 15, Index Start with a split Length field 💅:
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 |0|1|0|1|1|0|Rsv| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Look 16, Type Ext, Index Start and a split Length field, all in one go 🦋:
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 |1|1|0|1|1|0|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Look 17, Index Start, Index Stop, Length and Value, with the M bit 🍓:
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 |0|0|1|1|1|M|Rsv| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Look 18, the grand finale. Every field is in the fit: Type Ext, Index Start, Index Stop, Length and Value 💀✨:
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 |1|0|1|1|1|M|Rsv| Type Ext | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+Appendix E. Complete Example ✨
okay bestie, this one is literally my favourite because it's a full worked example that puts everything together 🎀 it's not built to squeeze out every last byte, it's built so you can see how Packet Headers and Message Headers get put together, and how addresses and attributes get packed up using Address Blocks and TLV Blocks 💅
so the packet's Packet Header has the phasseqnum flag set in its flags field (value 8) 🦋 which means there IS a Packet Sequence Number, but no Packet TLV Block, no drama 🌸
the packet holds one single message, length 54 octets 🍓 this message has the mhasorig, mhashoplimit, mhashopcount, and mhasseqnum flags set in its four-bit flags field (value 15) ✨ so it carries an Originator Address, a Hop Limit, a Hop Count, and a Message Sequence Number (which is type independent, iconic 👑). its four-bit Message Address Length field is 3, so the addresses in the message are four octets long, which means IPv4 addresses 💜
the message has a Message TLV Block with content length 9 octets, holding one Message TLV 🧚 this TLV has the thasvalue flag set in its flags octet (value 16), so it has a Value field, and the Value Length in front of it is 6 octets 🎀
then the message has two Address Blocks, and each one is followed by its own Address Block TLV Block 🫶
the first Address Block has 2 address prefixes 🌈 it has the ahaszerotail and ahassingleprelen flags set in its flags octet (value 48), so there's no Head at all (head-length is zero octets) 💀 the tail-length is 2 octets, which means mid-length is also two octets 😭 the two Tail octets of each address are left out (because ahaszerotail is set) and they're just zero. this Address Block has a single prefix length, and the Address Block TLV Block right after it is empty (content length 0 octets) 🙈
the second Address Block has 3 addresses 🔥 it has the ahashead flag set in its flags octet (value 128), with head-length 2 octets, and no Tail (tail-length is zero octets) ✨ so mid-length is two octets again 💅 it's followed by an Address Block TLV Block with content length 9 octets, holding two Address Block TLVs 👑
the first of those TLVs has the thasvalue flag set in its flags octet (value 16), and it has one single value of length 2 octets that applies to ALL the addresses in the Address Block 🦋 the second one has the thasmultiindex flag set in its flags octet (value 32), so it has no Value Length or Value fields at all 🌸 instead it has two Index fields, Index Start and Index Stop, which say which addresses this TLV applies to (an inclusive range, counting from zero) 🍓
here's the whole packet diagram so you can see it all lined up 💖
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (cont) | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Prefix Length |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|1 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Mid |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | TLV Type |0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Authors' Addresses 🫶
okay so here are the four people who wrote this 🌟 you literally want to know who to thank for all this brilliance 💜
Thomas Heide Clausen 🎀 LIX, Ecole Polytechnique
Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.thomasclausen.org/
Christopher M. Dearlove 🦋 BAE Systems ATC
Phone: +44 1245 242194 EMail: chris.dearlove@baesystems.com URI: http://www.baesystems.com/
Justin W. Dean 🌸 Naval Research Laboratory
Phone: +1 202 767 3397 EMail: jdean@itd.nrl.navy.mil URI: http://pf.itd.nrl.navy.mil/
Cedric Adjih 🍓 INRIA Rocquencourt
Phone: +33 1 3963 5215 EMail: Cedric.Adjih@inria.fr URI: http://menetou.inria.fr/~adjih/
that's the whole RFC, bestie!! 🌈✨💖 you made it through all 14 parts 😭👑
📦 where this page comes from
- ietf: rfc5444 2009-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms