RFC 8245

Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444

📅 published October 2017, from ietf

RFC 8245: Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444 🎀

Okay bestie, let's set the scene first 💖 This is an IETF Standards Track doc, published in October 2017 with ISSN 2070-1721. The authors are T. Clausen (Ecole Polytechnique), C. Dearlove (BAE Systems), U. Herberg, and H. Rogge (Fraunhofer FKIE). It updates RFC 5444 🦋 The header doesn't list anything it obsoletes, so it's not replacing anything. You can find the official page at https://www.rfc-editor.org/info/rfc8245 🧚

Internet Engineering Task Force (IETF)                        T. Clausen
Request for Comments: 8245                           Ecole Polytechnique
Updates: 5444                                                C. Dearlove
Category: Standards Track                                    BAE Systems
ISSN: 2070-1721                                               U. Herberg

                                                                H. Rogge
                                                         Fraunhofer FKIE
                                                            October 2017

Abstract 🌸

Okay so RFC 5444 gives us a generalized MANET packet/message format, and it also describes an intended use for multiplexed MANET routing protocol messages 💅 That use gets mandated by RFC 5498 whenever you're using the MANET port or protocol number it specifies. This document updates RFC 5444 by adding rules and recommendations for how the multiplexer works and how protocols can use the packet/message format ✨

The big one is the mandatory rules. They prohibit a bunch of uses that people suggested in different proposals, and those uses would have caused interoperability problems 😭 They'd also get in the way of protocol extension development, and/or make it impossible to use optional generic parsers. Not me making a list of banned moves 🙈

Status of This Memo 📜

This is an Internet Standards Track document 🔥

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🫶

Info about the current status of this document, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc8245 💜

Copyright (c) 2017 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 (https://trustee.ietf.org/license-info) as they stand on the date of publication of this document. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 🙏 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License ⚠️

Table of Contents 🗂️

   1. Introduction ....................................................4
      1.1. History and Purpose ........................................4
      1.2. Features of RFC 5444 .......................................4
           1.2.1. Packet/Message Format ...............................5
           1.2.2. Multiplexing and Demultiplexing .....................7
      1.3. Status of This Document ....................................8
   2. Terminology .....................................................8
   3. Applicability Statement .........................................9
   4. Information Transmission ........................................9
      4.1. Where to Record Information ................................9
      4.2. Message and TLV Type Allocation ...........................10
      4.3. Message Recognition .......................................11
      4.4. Message Multiplexing and Packets ..........................11
           4.4.1. Packet Transmission ................................12
           4.4.2. Packet Reception ...................................13
      4.5. Messages, Addresses, and Attributes .......................15
      4.6. Addresses Require Attributes ..............................16
      4.7. TLVs ......................................................18
      4.8. Message Integrity .........................................19
   5. Structure ......................................................19
   6. Message Efficiency .............................................20
      6.1. Address Block Compression .................................21
      6.2. TLVs ......................................................22
      6.3. TLV Values ................................................23
   7. Security Considerations ........................................24
   8. IANA Considerations ............................................24
   9. References .....................................................25
      9.1. Normative References ......................................25
      9.2. Informative References ....................................25
   Appendix A. Information Representation ............................27
   Appendix B. Automation ............................................28
   Acknowledgments ...................................................28
   Authors' Addresses ................................................29

1. Introduction ✨

[RFC5444] specifies a generalized packet/message format that's designed for use by MANET routing protocols 🦋

[RFC5444] was designed after experiences with [RFC3626]. That one tried to provide a packet/message format that could accommodate diverse protocol extensions, but it didn't fully succeed 😅 [RFC5444] was built as a common building block that both proactive and reactive MANET routing protocols can use 💖

[RFC5498] mandates the use of this packet/message format, and of the packet multiplexing process described in an appendix to [RFC5444]. That applies to protocols running over the MANET IP protocol and UDP port numbers allocated by [RFC5498] 🔥

1.1. History and Purpose 📖

Since [RFC5444] was published in 2009, a bunch of RFCs have come out that use its format, including [RFC5497], [RFC6130], [RFC6621], [RFC7181], [RFC7182], [RFC7183], [RFC7188], [RFC7631], and [RFC7722] 🌈 The ITU-T recommendation [G9903] also uses the [RFC5444] format to encode some of its control signals. Honestly, that's so iconic 👑 While writing these specs, people gained experience with [RFC5444]. They learned how to write specifications that use it so that a protocol stays forward compatible with future extensions, so that efficient messages can be created, and so that one efficient, generic parser can handle every protocol using [RFC5444] 🧚

During that same stretch, other people suggested using [RFC5444] in ways that would block the development of interoperable protocol extensions, could lead to inefficiencies, or could cause incompatibilities with generic parsers for [RFC5444]. None of these uses were explicitly prohibited by [RFC5444], but they're strongly discouraged 🙈 This document is meant to prohibit those uses. It also shares experiences from designing protocols with [RFC5444], and presents them as guidelines, along with their rationale, for future protocol designs that use [RFC5444] 💅

1.2. Features of RFC 5444 🎀

[RFC5444] does two main jobs:

  • It defines a packet/message format for use by MANET routing protocols. As far as [RFC5444] is concerned, each protocol that uses it is responsible for implementing the required message parsing and formation. It's natural, especially when you're implementing more than one such protocol, to implement these processes with protocol-independent packet/message creation and parsing procedures. However, [RFC5444] doesn't require this. Some comments in this document might be especially relevant to that case, but all that's required is that the messages passed to and from protocols are correctly formatted, and that packets containing those messages are correctly formatted as described in the following point 💖
  • Appendix A of [RFC5444], combined with the intended usage described in Appendix B of [RFC5444], specifies a multiplexing and demultiplexing process. In it, an entity that can be referred to as the "RFC 5444 multiplexer" manages packets that travel a single (logical) hop and contain messages owned by individual protocols 🦋 In this document, the "RFC 5444 multiplexer" is just called the "multiplexer", or the "demultiplexer" when it's doing that function. A packet can contain messages from more than one protocol ✨ This process is mandated by [RFC5498] for use on the MANET UDP port and IP protocol, which are alternative means for transporting packets 🔥 The multiplexer creates packets, parses Packet Headers, extracts messages, and passes each message to the appropriate protocol according to its type (the first octet in the message) 👑

1.2.1. Packet/Message Format

Okay, so here's the packet/message format of [RFC5444] and what it's built for 💅✨ Its main design goals are:

  • It's designed for carrying MANET routing protocol control signals 🛰️
  • It defines a packet as a Packet Header with a set of Packet TLVs (Type-Length-Value structures), followed by a set of messages 📦 Each message has a well-defined structure: a Message Header (designed for making processing and forwarding decisions), then a set of Message TLVs, and a set of (address, type, value) associations using Address Blocks and their Address Block TLVs. The packet/message format from [RFC5444] then enables simple and generic parsing logic for Packet Headers, Message Headers, and message content 🧠

A packet can include messages from different protocols, like the Neighborhood Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181], all in one transmission 🤝 This was observed in [RFC3626] to be beneficial, especially in wireless networks where media contention can be significant 📡

  • Its packets are designed to travel between two neighboring interfaces, which results in a single decrement of the IPv4 TTL or IPv6 hop limit 🦋 The Packet Header and any Packet TLVs can convey information relevant to that link (for example, the Packet Sequence Number can be used to count transmission successes across that link) 🔢 Packets are designed to be constructed for a single-hop transmission. A packet transmission following a successful packet reception is, by design, a new packet that can include all, some, or none of the received messages, plus possibly additional messages either received in separate packets or generated locally at that router 🔁 Messages can thus travel more than one hop and are designed to carry end-to-end protocol signals 🌍
  • It supports "internal extensibility" using TLVs 🧩 An extension can add information to an existing message without that information rendering the message unparseable or unusable by a router that does not support the extension. An extension is typically of the protocol that created the message being extended. For example, [RFC7181] adds information to the HELLO messages created by [RFC6130]. An extension can also be independent of the protocol. For example, [RFC7182] can add Integrity Check Value (ICV) and timestamp information to any message (or to a packet, thus extending the multiplexer) 🔐

Information, in the form of TLVs, can be added to the message as a whole (like the integrity information specified in [RFC7182]), or it can be associated with specific addresses in the message (like the Multipoint Relay (MPR) selection and link metric information added to HELLO messages by [RFC7181]) 🎀 An extension can also add addresses to a message 📍

  • It uses address aggregation into compact Address Blocks by exploiting commonalities between addresses 🗜️ In many deployments, addresses (IPv4 and IPv6) used on interfaces share a common prefix that doesn't need to be repeated. With IPv6, several addresses on the same interface might have common interface identifiers that don't need to be repeated either 💜
  • It sets up common namespaces, formats, and data structures for use by different protocols, so common parsing logic can be used 🪄 For example, [RFC5497] defines a generic TLV format for representing time information (like interval time or validity time) ⏰
  • It contains a minimal Message Header (a maximum of five elements: type, originator, sequence number, hop count, and hop limit) 🌸 That lets a router decide whether to locally process a message or forward it (which enables MANET-wide flooding of a message) without processing the body of the message 🏃‍♀️

1.2.2. Multiplexing and Demultiplexing

The multiplexer (and demultiplexer) is defined in Appendix A of [RFC5444] 🧚 Its purpose is to allow multiple protocols to share the same IP protocol or UDP port. That sharing became necessary because [RFC6130] and [RFC7181] were separated into different protocols, and because a single IP protocol and UDP port were allocated to all MANET protocols, including those following [RFC5498]. [RFC5498] states:

All interoperable protocols running on these well-known IANA allocations MUST conform to [RFC5444]. [RFC5444] provides a common format that enables one or more protocols to share the IANA allocations defined in this document unambiguously.

The multiplexer is the mechanism in [RFC5444] that makes that sharing possible 💖

The primary purposes of the multiplexer are to:

  • Accept messages from MANET protocols, which also indicate over which interface(s) the messages are to be sent and to which destination address. That destination can be a unicast address or the "LL-MANET-Routers" link-local multicast address defined in [RFC5498] 📬
  • Collect messages (possibly from multiple protocols) for the same local interface and destination into packets to be sent one logical hop, and send those packets using the MANET UDP port or IP protocol defined in [RFC5498] 📦
  • Extract messages from received packets and pass them to their owning protocols 📤

The multiplexer's relationship is with the protocols that own the corresponding Message Types. Where those protocols have their own relationships (for example, as extensions), that's up to the protocols themselves 🫶 For example, OLSRv2 [RFC7181] extends the HELLO messages created by NHDP [RFC6130]. However, the multiplexer will deliver HELLO messages to NHDP and will expect to receive HELLO messages from NHDP. The relationship between NHDP and OLSRv2 is between those two protocols 👯‍♀️

The multiplexer is also responsible for the Packet Header, including any Packet Sequence Number and Packet TLVs. It can accept some additional instructions from protocols, can pass additional information to protocols, and will follow some additional rules. See Section 4.4 🗺️

1.3. Status of This Document

This document updates [RFC5444] and is published on the Standards Track (rather than as Informational) 🏆 That's because it specifies and mandates constraints on the use of [RFC5444] that, if not followed, would make certain forms of extensions of those protocols impossible, impede the ability to generate efficient messages, or make desirable forms of generic parsers impossible 🙈

Each use of key words from [RFC2119] (see Section 2) can be considered an update to [RFC5444]. In most cases, these codify obvious best practice or constrain the use of [RFC5444] in the circumstances where this specification applies (see Section 3). In a few circumstances, the operation of [RFC5444] is modified. These are all circumstances that don't occur in its main and current uses, specifically by [RFC6130] and [RFC7181] (which might already include the requirement, particularly through [RFC7188]). Whenever such a modifying case updates [RFC5444], this specification says so explicitly ✨

2. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀 Yep, capitals are the magic switch 🔥

Use of those key words applies directly to existing and future implementations of [RFC5444]. It also applies to existing and future protocols that use or update that RFC 🌈

This document uses the terminology and notation defined in [RFC5444]. The terms "packet", "Packet Header", "message", "Message Header", "address", "Address Block", "TLV", "TLV Block", and other related terms are to be interpreted as described there 📖

Additionally, this document uses the following terminology 🧁

  • Full Type (of TLV): As per [RFC5444], the 16-bit combination of the TLV Type and Type Extension is given the symbolic name <tlv-fulltype>. This document uses the term "Full Type", which is not used in [RFC5444] but is assigned (by this document) as standard terminology 🏷️
  • Owning Protocol: As per [RFC5444], for each Message Type, a protocol (unless specified otherwise, the one making the IANA reservation for that Message Type) is designated as the "owning protocol" of that Message Type. The demultiplexer inspects the Message Type of each received message and delivers each message to its corresponding "owning protocol" 👑

3. Applicability Statement

This document doesn't specify a protocol. Instead, it documents constraints on how to design protocols that use the generic packet/message format defined in [RFC5444]. If those constraints aren't followed, forms of extensions of those protocols become impossible, the ability to generate efficient (small) messages is impeded, or desirable forms of generic parsers become impossible 🙅‍♀️ The use of the [RFC5444] format is mandated by [RFC5498] for all protocols running over the MANET protocol and port defined therein. So the constraints in this document apply to all protocols running over the MANET IP protocol or UDP port 🛡️ The constraints are strongly recommended for other uses of [RFC5444] 💅

4. Information Transmission

Protocols need to transmit information from one instance implementing the protocol to another 📨

4.1. Where to Record Information

A protocol has the following choices for where to put information for transmission 🗂️

  • in a TLV to be added to the Packet Header;
  • in a message of a type owned by another protocol; or
  • in a message of a type owned by the protocol.

The first case (a Packet TLV) can only be used when the information is to be carried one hop. It SHOULD only be used either where the information relates to the packet as a whole (for example, packet integrity check values and timestamps, as specified in [RFC7182]), or where the information is expected to have wider application than a single protocol 🔍 A protocol can also request that the Packet Header include Packet Sequence Numbers, but it doesn't control those numbers 🔢

The second case (in a message of a type owned by another protocol) is only possible if the adding protocol is an extension to the owning protocol. For example, OLSRv2 [RFC7181] is an extension of NHDP [RFC6130] 🧬

The third case is the normal case for a new protocol 🌟

A protocol extension can either simply be an update of the protocol (the third case), or it can be a new protocol that also updates another protocol (the second case). An example of the latter is OLSRv2 [RFC7181], a protocol that also extends the HELLO message owned by NHDP [RFC6130]. So it's an example of both the second and third cases (the latter using the OLSRv2-owned Topology Control (TC) message) 🥰 An extension to [RFC5444], such as [RFC7182], is considered to be an extension to all protocols. Protocols SHOULD be designed to enable extension by any of these means, and some of the rules in this document (in Sections 4.6 and 4.8, specifically) are there to help make that happen 🫧

4.2. Message and TLV Type Allocation ✨

Okay bestie, protocols SHOULD be conservative 🦋 about how many new Message Types they ask for, because there are only 224 allocatable Message Types total. That's it. 💀 Protocol designers SHOULD also think about whether different functions can be handled by different TLVs riding inside the same Message Type, instead of spinning up a whole new one. Smart, right? 🧠

The TLV Type space is bigger than the Message Type space, but it SHOULD still be used efficiently 💅. A TLV's Full Type is two octets, so there are way more TLV Full Types than Message Types. BUT, in some cases (right now that's LINK_METRIC from [RFC7181], and ICV and TIMESTAMP from [RFC7182], all in the global TLV Type space), a whole TLV Type with a complete set of 256 TLV Full Types gets defined (though not necessarily allocated). 😭

Each Message Type gets its own block of Message-Type-specific TLV Types (128 to 233, each with 256 type extensions), for both Address Block TLV Types and Message TLV Types. When a TLV is specific to a message, TLV Types from inside these blocks SHOULD be used in preference to the Message-Type-independent Message TLV Types (0 to 127, each with 256 type extensions). Main character energy for the specific ones 👑.

The Expert Review guidelines in [RFC5444] are updated accordingly, as described in Section 8. 🫶

4.3. Message Recognition 🌸

Okay so a message has a Message Header and a Message Body, and the Message TLV Block counts as part of the Body (noted!). The Message Header holds info whose main job is deciding whether to process the message and whether to forward it. 🎀

A protocol might need to recognize a message it has already received, especially a flooded one, so it can decide whether to process and/or forward it, or just toss it 🙈. A message can be recognized as previously seen if its Message Header has enough info. A message MUST be recognized that way by the combo of its Message Type, Originator Address, and Message Sequence Number. Including Message Type lets each protocol manage its own Message Sequence Numbers, and it also allows for different Message Types having wildly different transmission rates ✨. As an example, [RFC7181] has a general purpose process for managing processing and forwarding decisions, though it's specifically for use with MPR flooding. (Blind flooding can be handled similarly by assuming that all other routers are MPR selectors. In that case it's not necessary to tell apart the interfaces a message was received on. 🧚)

Most protocol information is thus contained in the Message Body. A model of how that information can be viewed is described in Sections 4.5 and 4.6. To use that model, addresses (for example, of neighboring or otherwise known routers) SHOULD be recorded in Address Blocks, not as data in TLVs. Recording addresses in TLV Value fields both breaks the model of addresses as identities and associated information (attributes), and also inhibits address compression. 🙅‍♀️ However, in some cases, alternative addresses (e.g., hardware addresses when the Address Block is recording IP addresses) can be carried as TLV Values. Also, a message contains a Message Address Length field that can be used to allow carrying alternative message sizes. But only one length of addresses can be used in a single message, in all Address Blocks and the Originator Address, and it's established by the router and protocol generating the message. Ngl that's a lot, but it all matters 💖.

4.4. Message Multiplexing and Packets 🦋

The multiplexer has to handle message multiplexing into packets and the transmission of those packets, plus packet reception and demultiplexing back into messages. The multiplexer and the protocols that use it are subject to the rules below, so pay attention 💅.

4.4.1. Packet Transmission

Packets are formed for transmission through the following steps:

  • Outgoing messages are created by their owning protocol and MAY be modified by any extending protocols if the owning protocol permits this. Messages MAY also be forwarded by their owning protocol. It is strongly RECOMMENDED that messages are not modified in the latter case, other than updates to their hop count and hop limit fields, as described in Section 7.1.1 of [RFC5444]. Note that this includes having an identical octet representation, including not allowing a different TLV representation of the same information. This is because it enables end-to-end authentication that ignores (zeros) those two fields (only), as is done in the Message TLV ICV (Integrity Check Value) calculations in [RFC7182]. Protocols MUST document their behavior with regard to modifiability of messages. 📝
  • Outgoing messages are then sent to the multiplexer. The owning protocol MUST indicate which interface(s) the messages are to be sent on and their destination address. Note that packets travel one hop, so the destination is either a link-local multicast address (if the packet is being multicast) or the address of the neighbor interface the packet is sent to. 🎯
  • The owning protocol MAY request that messages are kept together in a packet, and the multiplexer SHOULD respect this request if at all possible. The multiplexer SHOULD combine messages that are sent on the same interface in a packet, whether they come from the same or different protocols, provided that in doing so the multiplexer does not cause an IP packet to exceed the current Maximum Transmission Unit (MTU). Note that the multiplexer cannot fragment messages. Creating suitably sized messages that won't cause the MTU to be exceeded if sent in a single message packet is the responsibility of the protocol generating the message. If a larger message is created, then only IP fragmentation is available to allow the packet to be sent, and that's generally considered undesirable, especially when transmission can be unreliable 😬.
  • The multiplexer MAY delay messages in order to assemble more efficient packets. It MUST respect any constraints on such delays requested by the protocol if it is practical to do so. ⏳
  • If requested by a protocol, the multiplexer MUST (and otherwise MAY) include a Packet Sequence Number in the packet. Such a request MUST be respected as long as the protocol is active. Note that the errata to [RFC5444] indicates that the Packet Sequence Number SHOULD be specific to the interface on which the packet is sent. This specification updates [RFC5444] by requiring that this sequence number MUST be specific to that interface, and also that separate sequence numbers MUST be maintained for each destination to which packets are sent with included Packet Sequence Numbers. Addition of Packet Sequence Numbers MUST be consistent (i.e., for each interface and destination, the Packet Sequence Number MUST be added to all packets or to none). 🔢
  • An extension to the multiplexer MAY add TLVs to the packet. It MAY also add TLVs to the messages, in which case it is considered as also extending the corresponding protocols. For example, [RFC7182] can be used by the multiplexer to add Packet TLVs or Message TLVs, or it can be used by the protocol to add Message TLVs. 🧩

4.4.2. Packet Reception

When a packet is received, the following steps are performed by the demultiplexer and by protocols:

  • The Packet Header and the organization into the messages that it contains MUST be verified by the demultiplexer. 🔍
  • The packet and/or the messages it contains MAY also be verified by an extension to the demultiplexer, such as [RFC7182]. ✅
  • Each message MUST be sent to its owning protocol or discarded if the Message Type is not recognized. The demultiplexer MUST also make available to the protocol the Packet Header, and the source and destination addresses in the IP datagram that included the packet. 📬
  • The demultiplexer MUST remove any Message TLVs that were added by an extension to the multiplexer. The message MUST be passed on to the protocol exactly as received from (another instance of) the protocol. This is, in part, an implementation detail. For example, an implementation of the multiplexer and of [RFC7182] could add a Message TLV either in the multiplexer or in the protocol, and remove it in the same place on reception. An implementation MUST ensure that the message passed to a protocol is as it would be passed from that protocol by the same implementation, i.e., that the combined implementation on a router is self-consistent, and that messages included in packets by the multiplexer are independent of this implementation detail. 🧼
  • The owning protocol MUST verify each message for correctness, and it MUST allow any extending protocol(s) to also contribute to this verification. 🕵️‍♀️
  • The owning protocol MUST process each message. In some cases, which will be defined in the protocol specification, this processing will determine that the message will be ignored. Except in the latter case, the owning protocol MUST also allow any extending protocols to process the message. 🛠️
  • The owning protocol MUST manage the hop count and/or hop limit in the message. It is RECOMMENDED that these are handled as described in Appendix B of [RFC5444]. They MUST be so handled if using hop-count-dependent TLVs, such as those defined in [RFC5497]. 🔁

4.4.2.1. Other Information

In addition to the messages going between the multiplexer and the protocols in each direction, the following additional information (summarized from other sections in this specification) can be exchanged. 💌

  • The packet source and destination addresses MUST be sent from the demultiplexer to the protocol.
  • The Packet Header, including the Packet Sequence Number, MUST be sent from the (de)multiplexer to the protocol if present. (An implementation MAY choose to only do so, or to only report the Packet Sequence Number, on request.)
  • A protocol MAY require that all outgoing packets contain a Packet Sequence Number. 🔐
  • The interface over which a message is to be sent, and its destination address, MUST be sent from protocol to multiplexer. The destination address MAY be a multicast address, in particular the LL-MANET-Routers link-local multicast address defined in [RFC5498]. 📡
  • A request to keep messages together in one packet MAY be sent from protocol to multiplexer. 🫧
  • A requested maximum message delay MAY be sent from protocol to multiplexer. 🌈

The protocol SHOULD also be aware of the MTU that will apply to its messages, if this is available. 💜

4.5. Messages, Addresses, and Attributes ✨

okay so the info inside a Message Body (that includes Message TLVs and Address Block TLVs) is basically made of three things 🎀

  • Attributes of the message. Each one has a Full Type, a length, and a Value (of that length).
  • A set of addresses. These get carried in one or more Address Blocks.
  • Attributes of each address. Same deal here: a Full Type, a length, and a Value (of that length).

Attributes live inside TLVs 💅 For Message TLVs it's giving one-to-one, one TLV per attribute. For Address Block TLVs it's a bit more of a glow-up: one TLV can carry attributes for multiple addresses, but only one attribute per address. And attributes for different addresses can be the same or different 🦋

[RFC5444] requires that when a TLV Full Type is defined, then it MUST also define how to handle the cases of multiple TLVs of the same type applying to the same information element 🫶 Like, when more than one Packet TLV of the same TLV Full Type shows up in the same Packet Header, when more than one Message TLV of the same TLV Full Type is in the same Message TLV Block, or when more than one Address Block TLV of the same TLV Full Type applies to the same value of any address. Everyone needs a plan for the duplicates 😭 It is RECOMMENDED that when defining a new TLV Full Type, a rule of the following form is adopted:

  • If used, there MUST be only one TLV of that Full Type associated with the packet (Packet TLV), message (Message TLV), or any value of any address (Address Block TLV).

Note that this applies to address values 👀 An address can appear more than once in a message, but the restriction on associating TLVs with addresses covers all copies of that address. It is RECOMMENDED that addresses are not repeated in a message, bestie 🌸

A conceptual way to view this information is described in Appendix A 🧚

4.6. Addresses Require Attributes 💜

It is not mandatory in [RFC5444] to associate an address with attributes using Address Block TLVs. So information about an address could, in principle, be carried using:

  • The simple presence of an address.
  • The ordering of addresses in an Address Block.
  • The use of different meanings for different Address Blocks.

This specification, however, requires that those methods of carrying information MUST NOT be used for any protocol using [RFC5444]. Information about the meaning of an address MUST only be carried using Address Block TLVs. No shortcuts, periodt 💅

In addition, rules for the extensibility of OLSRv2 and NHDP are described in [RFC7188]. This specification extends their applicability to other uses of [RFC5444] ✨ So these rules apply everywhere, not just to the two protocols 🔥

These rules are:

  • A protocol MUST NOT assign any meaning to the presence or absence of an address (either in a Message or in a given Address Block in a Message), to the ordering of addresses in an Address Block, or to the division of addresses among Address Blocks.
  • A protocol MUST NOT reject a message based on the inclusion of a TLV of an unrecognized type. The protocol MUST ignore any such TLVs when processing the message. The protocol MUST NOT remove or change any such TLVs if the message is to be forwarded unchanged.
  • A protocol MUST NOT reject a message based on the inclusion of an unrecognized Value in a TLV of a recognized type. The protocol MUST ignore any such Values when processing the message but MUST NOT ignore recognized Values in such a TLV. The protocol MUST NOT remove or change any such TLVs if the message is to be forwarded unchanged.
  • Similar restrictions to the two preceding points apply to the demultiplexer, which also MUST NOT reject a packet based on an unrecognized message. Although it will reject any such messages, it MUST deliver any other messages in the packet to their owning protocols 🧚

The following points indicate the reasons for these rules based on considerations of extensibility and efficiency 🍓

Assigning a meaning to the presence, absence, or location of an address would reduce the extensibility of the protocol. It would also prevent the approach to information representation described in Appendix A, and reduce the options available for message optimization described in Section 6. Not it, honestly 🙈

To see how the simple presence of an address conveying information would have restricted the development of an extension, two examples are considered: one actual (included in the base specification, but which could have been added later) and one hypothetical 🔍

The basic function of NHDP's HELLO messages [RFC6130] is to indicate that addresses are of neighbors, using the LINK_STATUS and OTHER_NEIGHB TLVs. (The message can also indicate the router's own addresses, which could also serve as a further example.)

An extension to NHDP might decide to use the HELLO message to report that an address is one that could be used for a specialized purpose rather than for normal NHDP-based purposes. Such an example already exists in the use of LOST Values in the LINK_STATUS and OTHER_NEIGHB TLVs to report that an address is of a router known not to be a neighbor. Okay this is actually so clever ✨

A future example could be to indicate that an address is to be added to a "blacklist" of addresses not to be used. This would use a new TLV (or a new Value of an existing TLV, see below). If no other TLVs were attached to such a blacklisted address, then an unmodified implementation of NHDP would ignore that address, as required. If any other TLVs were attached to that address, then that implementation would process that address for those TLVs. Had NHDP been designed so that just the presence of an address indicated a neighbor, this blacklist extension would not be possible, as an unmodified implementation of NHDP would treat all blacklisted addresses as neighbors. Yikes, the bad vibes would spread 💀

Rejecting a message because it contains an unrecognized TLV Type or an unrecognized TLV Value reduces the extensibility of the protocol 🥺

For example, OLSRv2 [RFC7181] is, among other things, an extension to NHDP. It adds information to addresses in an NHDP HELLO message using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP (for example, to support Simplified Multicast Flooding (SMF) [RFC6621]) will still process the HELLO message, ignoring the LINK_METRIC TLVs. Everybody gets to hang 🫶

Also, the blacklisting described in the example above could be signaled not with a new TLV but with a new Value of a LINK_STATUS or OTHER_NEIGHB TLV (requiring an IANA allocation as described in [RFC7188]), as is already done in the LOST case 🎀

The creation of Multi-Topology OLSRv2 (MT-OLSRv2) [RFC7722], as an extension to OLSRv2 that can interoperate with unextended instances of OLSRv2, would not have been possible without these restrictions (which were applied to NHDP and OLSRv2 by [RFC7188]). So these rules are literally the reason it exists 👑

These restrictions do not, however, mean that added information is completely ignored for purposes of the base protocol 🙃 Suppose that a faulty implementation of OLSRv2 (including NHDP) creates a HELLO message that assigns two different values of the same link metric to an address, something that is not permitted by [RFC7181]. A receiving OLSRv2-aware implementation of NHDP will reject such a message, even though a receiving OLSRv2-unaware implementation of NHDP will process it. This is because the OLSRv2-aware implementation has access to additional information (that the HELLO message is definitely invalid and the message is best ignored), as it is unknown what other errors it might contain. Context is everything, fr fr 💅

4.7. TLVs 🎀

Within a message, the attributes are represented by TLVs. Particularly for Address Block TLVs, different TLVs can represent the same information 👀 For example, using the LINK_STATUS TLV defined in [RFC6130], if some addresses have Value SYMMETRIC and some have Value HEARD, arranged in that order, then this information can be represented using two single-value TLVs or one multivalue TLV. The latter can be used even if the addresses are not so ordered. Two ways to say the same thing, iykyk 🦋

A protocol MAY use any representation of information using TLVs that convey the required information. A protocol SHOULD use an efficient representation, but this is a quality of implementation issue. A protocol MUST recognize any permitted representation of the information. Even if it chooses to, for example, only use multivalue TLVs, it MUST recognize single-value TLVs (and vice versa). Read the room, but also read every format 🧚

A protocol defining new TLVs MUST respect the naming and organizational rules in [RFC7631]. It SHOULD follow the guidance in [RFC7188], see Section 6.3. (This specification does not, however, relax the application of [RFC7188] where it is mandated.) Rules are rules, bestie 📜

4.8. Message Integrity 🔐

In addition to not rejecting a message due to unknown TLVs or TLV Values, a protocol MUST NOT reject a message based on the inclusion of a TLV of an unrecognized type. The protocol MUST ignore any such TLVs when processing the message. The protocol MUST NOT remove or change any such TLVs if the message is to be forwarded unchanged. Such behavior may have the following consequences:

  • It might disrupt the operation of an extension of which it is unaware. Note that it is the responsibility of a protocol extension to handle interoperation with unextended instances of the protocol. For example, OLSRv2 [RFC7181] adds an MPR_WILLING TLV to HELLO messages (created by NHDP [RFC6130], of which it is an extension) to recognize this case (and for other reasons) ✨
  • It would prevent the operation of end-to-end message authentication using [RFC7182] or any similar mechanism. The use of immutable (apart from hop count and/or hop limit) messages by a protocol is strongly RECOMMENDED for that reason. Protect the message, protect the vibes 🛡️💖

5. Structure ✨

okay so this part is about the format itself from [RFC5444], not the protocols that use it. think bits and boxes, not the vibes of the apps built on top 💅

The elements in [RFC5444] have structures that are managed by a few flags fields:

  • Packet flags field (4 bits, 2 used) that manages the contents of the Packet Header. 🎀
  • Message flags field (4 bits, 4 used) that manages the contents of the Message Header. 🦋
  • Address Block flags field (8 bits, 4 used) that manages the contents of an Address Block. 🌸
  • TLV flags field (8 bits, 5 used) that manages the contents of a TLV. 💜

Note that all of these flags are structural. they say which elements are present or absent, field lengths, or whether a field has one value or multiple values in it. ngl that's a very clean job for a flag 😭

In the current version of [RFC5444], indicated by version number 0 in the <version> field of the Packet Header, unused bits in these flags fields are stated as "are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception". for the avoidance of any compatibility issues with version number 0, this is updated to "MUST each be cleared ('0') on transmission and MUST be ignored on reception". no notes, bestie, just do it 🫶

If a specification updating [RFC5444] introduces new flags in one of the flags fields of a packet, Address Block, or TLV (there being no unused flags in the message flags field), the following rules MUST be followed:

  • The version number contained in the <version> field of the Packet Header MUST NOT be 0.
  • The new flag(s) MUST indicate the structure of the corresponding packet, Address Block, or TLV. They MUST NOT be used to indicate any other semantics, such as message forwarding behavior.

An update that would be incompatible with the current specification of [RFC5444] SHOULD NOT be created unless there is a pressing reason for it that cannot be satisfied using the current specification (e.g., by use of a suitable Message TLV or Address Block TLV). it's giving "last resort" energy and I respect it 💅

During the development of [RFC5444] (and since publication), some proposals were made to use these RESERVED flags to specify behavior rather than structure, message forwarding in particular. after due consideration, these were not accepted, for a number of reasons. the reasons include that message forwarding is protocol specific. for example, [RFC7181] forwards messages using its MPR mechanism rather than a "blind" flooding mechanism. (these proposals were made while [RFC5444] was still in development, when there were unused message flags. the later addition of a 4-bit Message Address Length field left no unused message flags, but the other flags fields still have unused flags.) the fact that the drama happened is so iconic 🔥

6. Message Efficiency

the whole point here is that organizing addresses into the same or different Address Blocks, reordering addresses within a block, and the flexible TLV spec all let you avoid repeating info. that means smaller messages, which is literally the goal 🍓 There are no algorithms for address organization, compression, or TLV usage in [RFC5444]. any algorithms that leave the information content unchanged MAY be used when generating a message. see also Appendix B 🧚

6.1. Address Block Compression

[RFC5444] allows the addresses in an Address Block to be compressed. A protocol generating a message SHOULD compress addresses as much as it can. compression is a whole mood ✨

Addresses in an Address Block consist of a Head, a Mid, and a Tail. all addresses in an Address Block have the same Head and Tail but different Mids. each part has a length that is greater than or equal to zero, and the sum of the lengths is the address length. (the Mid length is deduced from this relationship.) compression is possible when the Head and/or the Tail have non-zero length. an extra compression is possible when the Tail consists of all zero-valued octets. expected use cases include IPv4 and IPv6 addresses from within the same prefix, which therefore have a common Head, IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with a common Tail representing an interface identifier that might also have a common Head. note that when IPv4 addresses have a common Head, their Tail will usually have length zero 🫶

For example:

  • The IPv4 addresses 192.0.2.1 and 192.0.2.2 would, for greatest efficiency, have a 3-octet Head, a 1-octet Mid, and a 0-octet Tail.
  • The IPv6 addresses 2001:DB8:prefix1:interface and 2001:DB8:prefix2:interface that use the same interface identifier but completely different prefixes (except as noted) would, for greatest efficiency, have a 4-octet Head, a 4-octet Mid, and an 8-octet Tail. (they could have a larger Head and/or Tail and a smaller Mid if the prefixes have any octets in common.) the main character energy of IPv6 is real 👑

Putting addresses into a message efficiently also requires considering the following:

  • The split of the addresses into Address Blocks.
  • The order of the addresses within the Address Blocks.

this split and/or ordering is for efficiency only. it does not provide any information. the split of the addresses affects both the address compression and the TLV efficiency (see Section 6.2). the order of the addresses within an Address Block affects only the TLV efficiency. however, using more Address Blocks than needed can increase the message size, because of the overhead of each Address Block and the following TLV Block, and/or because additional TLVs may now be required. so don't over-split, bestie 🙈

The order of addresses can be as simple as sorting the addresses. but if many addresses have the same TLV Types attached, it might be more useful to put those addresses together, either within the same Address Block as other addresses or in a separate Address Block. a separate Address Block might also improve address compression, for example, if more than one address form is used (such as from independent subnets). an example of possible use of address ordering is a HELLO message from [RFC6130] that could be generated with local interface addresses first and neighbor addresses later. these could be in separate Address Blocks 🌈

6.2. TLVs

when considering TLVs, the main opportunities for more efficient messages are in Address Block TLVs rather than Message TLVs. the approaches described here apply to each Address Block 💅

An Address Block TLV provides attributes for one address or for a contiguous set of addresses (as stored in the Address Block), with a special case for when this set is all of the addresses in the Address Block. when associated with more than one address, a TLV can be single value (associating the same attribute with each address) or multivalue (associating a separate attribute with each address).

the approach that is simplest to implement is to use multivalue TLVs that cover all affected addresses. however, unless care is taken to order addresses appropriately, these affected addresses might not all be contiguous. some approaches to this are the following:

  • Reorder the addresses. it is, for example, possible (though not straightforward, and beyond the scope of this document to describe exactly how) to order all addresses in a HELLO message as specified in [RFC6130] so that all TLVs used only cover contiguous addresses. this is even possible if the MPR TLV specified in OLSRv2 [RFC7181] is added, but it is not possible in general if the LINK_METRIC TLV specified in OLSRv2 [RFC7181] is also added. 🧩
  • Allow the TLV to span addresses that do not need the corresponding attribute, and use a Value that indicates no information; see Section 6.3.
  • Use more than one TLV. note that this can be efficient when the TLVs become single-value TLVs. in a typical case where a LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with enough addresses sorted appropriately, two single-value TLVs can be more efficient than one multivalue TLV. if only one Value is involved (such as NHDP in a steady state with LINK_STATUS equal to SYMMETRIC in all cases), then one single-value TLV SHOULD always be used. ✨

6.3. TLV Values

if, for example, an Address Block contains five addresses, and the first two and the last two require Values assigned using a LINK_STATUS TLV but the third does not, then this can be indicated using two TLVs. it is, however, more efficient to do this with one multivalue LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED (as defined in [RFC7188]). in general, use of UNSPECIFIED Values allows use of fewer TLVs and is thus often an efficiency gain. however, a long run of consecutive UNSPECIFIED Values (more than the overhead of a TLV) can make using more TLVs more efficient. the math ain't mathing for everyone, but it's giving smart 🧠

some other TLVs might need a different approach. as noted in [RFC7188], but implicitly permissible before then, the LINK_METRIC TLV (defined in [RFC7181]) has two octet Values whose first four bits are flags indicating whether the metric applies in four cases. if these are all zero, then the metric does not apply in this case, which is thus the equivalent of an UNSPECIFIED Value 🦋

[RFC7188] requires that protocols that extend [RFC6130] and [RFC7181] allow unspecified values in TLVs where applicable. it is here RECOMMENDED that all protocols follow that advice. in particular, it is RECOMMENDED that when defining an Address Block TLV with discrete Values, an UNSPECIFIED Value is defined with the same value (255), and a modified approach should be used where possible for other Address Block TLVs (for example, as is done for a LINK_METRIC TLV, though not necessarily using that exact approach). 👑

it might be argued that providing an unspecified value (of any form) to allow an Address Block TLV to cover unaffected addresses is not always necessary, because addresses can be reordered to avoid this. however, ordering addresses to avoid this for all TLVs that might be used is not, in general, possible. so the unspecified value stays, periodt 💅

In addition, [RFC7188] recommends that if a TLV Value (per address for an Address Block TLV) has a single-length that does not match the defined length for that TLV Type, then the following rules are adopted:

  • If the received single-length is greater than the expected single length, then the excess octets MUST be ignored.
  • If the received single-length is less than the expected single length, then the absent octets MUST be considered to have all bits cleared (0).

This specification RECOMMENDS a similar rule for all protocols defining new TLVs. 🌸

7. Security Considerations

this document doesn't specify a protocol. it provides rules and recommendations for how to design protocols using [RFC5444], and those protocols' security considerations apply. 🔐

If the recommendation from Section 4.4.1 is followed, which specifies that messages are not modified (except for hop count and hop limit) when forwarded, then the security framework for [RFC5444] (specified in [RFC7182]) can be used in full. if that recommendation is not followed, then the Packet TLVs from [RFC7182] can be used, but the Message TLVs from [RFC7182] cannot be used as intended. this is the part where you really cannot skip the fine print 😭⚠️

In either case, a protocol using [RFC5444] MUST document whether it is using [RFC7182] and, if so, how. no vague vibes allowed on this one, bestie 💀

8. IANA Considerations 🦋

Okay, so the Expert Review guidelines in [RFC5444] got a glow-up in this doc. They now include a general requirement that:

  • The Designated Expert will consider the limited TLV and (especially) Message Type space when considering whether a requested allocation is allowed and whether a more efficient allocation than that requested is possible. 💅

IANA added this document as a reference for these Mobile Ad hoc NETwork (MANET) Parameters registries, so it's officially part of the paperwork now 📋✨:

  • Message Types
  • Packet TLV Types
  • Message TLV Types
  • Address Block TLV Types

9. References 📚

9.1. Normative References

These are the ones you absolutely need to read, bestie 🫶

9.2. Informative References

These are the extra-credit reads, but they're super worth a peek 🌸

Appendix A. Information Representation 🧚

Okay, this part is a conceptual way to think about the info inside a message 🧠 It can be the basis for parsing a message into information, and for building a message from the information it's supposed to hold. There's no requirement that a protocol does it this way though, so no pressure! This approach can help when designing a protocol, or when a protocol (or generic parser) implementer is building something 🔥

A message (excluding the Message Header) can be represented by two maps, which might be multivalued 🗺️

Message: (Full Type) -> (length, Value)
Address: (address, Full Type) -> (length, Value)

These maps, plus a representation of the Message Header, can be the basis for a generic representation of the info in a message. You can make these maps by parsing a message, or build them using the protocol rules for creating a message and later convert them into the octet form of the message specified in [RFC5444] ✨

Now, any software that represents info in the form above could specify an Application Programming Interface (API) for itself, obviously 💅 But this doc doesn't propose one, and here's why: first, a full API would be specific to a programming language 🙈 Second, even inside this framework there are different ways to make such an interface. For example, and for illustrative purposes only, here are the alternative address mappings:

  • Input: address and Full Type. Output: list of (length, Value) pairs. Note that for most Full Types, it will be known in advance that this list will have a length of zero or one. The list of addresses that can be used as inputs with non-empty output would need to be provided as a separate output.
  • Input: Full Type. Output: list of (address, length, Value) triples. As this list length can be significant, a possible output will be one or two iterators that let you iterate through that list. (One iterator that can detect the end of the list, or a pair of iterators specifying a range.)

Other differences in the interface might be about things like the ordering of output lists, which is totally a vibe-check kind of thing 🌈

Appendix B. Automation 🤖

There's room for building a protocol-independent optimizer for [RFC5444] messages! 🎀 It would do smart address re-organization (ordering and Address Block separation) and TLV changes (the number of them, whether they're single value or multivalue, and using unspecified values) to make messages more compact 📦 How much you gain depends on how efficiently the original message got created and the specific details of the message. Also, this process cannot be TLV Type independent. For example, a LINK_METRIC TLV has a more complicated Value structure than a LINK_STATUS TLV does if using UNSPECIFIED Values 😭

Such a protocol-independent optimizer MAY be used by the router generating a message but MUST NOT be used on a message that is forwarded unchanged by a router. 🚫 Important, so read it twice!

Acknowledgments 🫶

The authors thank Cedric Adjih (INRIA) and Justin Dean (NRL) for their contributions as authors of RFC 5444. Thank you, legends 👑

Authors' Addresses 💌

Thomas Clausen:

Thomas Clausen
Ecole Polytechnique
91128 Palaiseau Cedex
France

Phone: +33-6-6058-9349
Email: T.Clausen@computer.org
URI:   http://www.thomasclausen.org

Christopher Dearlove:

Christopher Dearlove
BAE Systems Applied Intelligence Laboratories
West Hanningfield Road
Great Baddow, Chelmsford
United Kingdom

Email: chris.dearlove@baesystems.com
URI:   http://www.baesystems.com

Ulrich Herberg:

Ulrich Herberg

Email: ulrich@herberg.name
URI:   http://www.herberg.name

Henning Rogge:

Henning Rogge
Fraunhofer FKIE
Fraunhofer Strasse 20
53343 Wachtberg
Germany

Email: henning.rogge@fkie.fraunhofer.de
📦 where this page comes from