tech-invite   World Map
3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8245

Proposed STD
Pages: 29
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: MANET

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

Part 1 of 2, p. 1 to 19
None       Next Section

Updates:    5444


Top       ToC       Page 1 
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


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

Abstract

   RFC 5444 specifies a generalized Mobile Ad Hoc Network (MANET)
   packet/message format and describes an intended use for multiplexed
   MANET routing protocol messages; this use is mandated by RFC 5498
   when using the MANET port or protocol number that it specifies.  This
   document updates RFC 5444 by providing rules and recommendations for
   how the multiplexer operates and how protocols can use the
   packet/message format.  In particular, the mandatory rules prohibit a
   number of uses that have been suggested in various proposals and that
   would have led to interoperability problems, to the impediment of
   protocol extension development, and/or to an inability to use
   optional generic parsers.

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 has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8245.

Top      ToC       Page 2 
Copyright Notice

   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) 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 3 
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

Top      ToC       Page 4 
1.  Introduction

   [RFC5444] specifies a generalized packet/message format that is
   designed for use by MANET routing protocols.

   [RFC5444] was designed following experiences with [RFC3626], which
   attempted to provide a packet/message format accommodating diverse
   protocol extensions but did not fully succeed.  [RFC5444] was
   designed as a common building block for use by both proactive and
   reactive MANET routing protocols.

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

1.1.  History and Purpose

   Since the publication of [RFC5444] in 2009, several RFCs have been
   published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181],
   [RFC7182], [RFC7183], [RFC7188], [RFC7631], and [RFC7722], that use
   the format of [RFC5444].  The ITU-T recommendation [G9903] also uses
   the format of [RFC5444] for encoding some of its control signals.  In
   developing these specifications, experience with the use of [RFC5444]
   has been acquired, specifically with respect to how to write
   specifications using [RFC5444] so as to ensure forward compatibility
   of a protocol with future extensions, to enable the creation of
   efficient messages, and to enable the use of an efficient and generic
   parser for all protocols using [RFC5444].

   During the same time period, other suggestions have been made to use
   [RFC5444] in a manner that would inhibit the development of
   interoperable protocol extensions, that would potentially lead to
   inefficiencies, or that would lead to incompatibilities with generic
   parsers for [RFC5444].  While these uses were not all explicitly
   prohibited by [RFC5444], they are strongly discouraged.  This
   document is intended to prohibit such uses, to present experiences
   from designing protocols using [RFC5444], and to provide these as
   guidelines (with their rationale) for future protocol designs using
   [RFC5444].

1.2.  Features of RFC 5444

   [RFC5444] performs two main functions:

   o  It defines a packet/message format for use by MANET routing
      protocols.  As far as [RFC5444] is concerned, it is up to each
      protocol that uses it to implement the required message parsing

Top      ToC       Page 5 
      and formation.  It is natural, especially when implementing more
      than one such protocol, to implement these processes using
      protocol-independent packet/message creation and parsing
      procedures, however, this is not required by [RFC5444].  Some
      comments in this document might be particularly applicable to such
      a case, but all that is 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.

   o  Appendix A of [RFC5444], combined with the intended usage
      described in Appendix B of [RFC5444], specifies a multiplexing and
      demultiplexing process whereby an entity that can be referred to
      as the "RFC 5444 multiplexer" manages packets that travel a single
      (logical) hop and contain messages that are owned by individual
      protocols.  Note that in this document, the "RFC 5444 multiplexer"
      is referred to as the "multiplexer", or as the "demultiplexer"
      when performing that function.  A packet can contain messages from
      more than one protocol.  This process is mandated for use on the
      MANET UDP port and IP protocol (alternative means for the
      transport of packets) by [RFC5498].  The multiplexer is
      responsible for creating packets and for parsing Packet Headers,
      extracting messages, and passing them to the appropriate protocol
      according to their type (the first octet in the message).

1.2.1.  Packet/Message Format

   Among the characteristics and design objectives of the packet/message
   format of [RFC5444] are the following:

   o  It is designed for carrying MANET routing protocol control
      signals.

   o  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 consisting of a Message
      Header (designed for making processing and forwarding decisions)
      followed by 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 the
      use of simple and generic parsing logic for Packet Headers,
      Message Headers, and message content.

      A packet can include messages from different protocols, such as
      the Neighborhood Discovery Protocol (NHDP) [RFC6130] and the
      Optimized Link State Routing Protocol version 2 (OLSRv2)

Top      ToC       Page 6 
      [RFC7181], in a single transmission.  This was observed in
      [RFC3626] to be beneficial, especially in wireless networks where
      media contention can be significant.

   o  Its packets are designed to travel between two neighboring
      interfaces, which will result in a single decrement of the IPv4
      TTL or IPv6 hop limit.  The Packet Header and any Packet TLVs can
      thus 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.

   o  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 to be extended, for example,
      [RFC7181] adds information to the HELLO messages created by
      [RFC6130].  However, 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 (such as the integrity information specified in [RFC7182])
      or can be associated with specific addresses in the message (such
      as the Multipoint Relay (MPR) selection and link metric
      information added to HELLO messages by [RFC7181]).  An extension
      can also add addresses to a message.

   o  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 need not be repeated.  Using IPv6, several addresses (of the
      same interface) might have common interface identifiers that need
      not be repeated.

   o  It sets up common namespaces, formats, and data structures for use
      by different protocols where common parsing logic can be used.
      For example, [RFC5497] defines a generic TLV format for
      representing time information (such as interval time or validity
      time).

Top      ToC       Page 7 
   o  It contains a minimal Message Header (a maximum of five elements:
      type, originator, sequence number, hop count, and hop limit) that
      permit decisions regarding whether to locally process a message or
      forward a message (thus enabling 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 was made necessary by the
   separation of [RFC6130] from [RFC7181] as separate protocols and by
   the allocation of a single IP protocol and UDP port to all MANET
   protocols, including those protocols following [RFC5498], which
   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 enables that
   sharing.

   The primary purposes of the multiplexer are to:

   o  Accept messages from MANET protocols, which also indicate over
      which interface(s) the messages are to be sent and to which
      destination address.  The latter can be a unicast address or the
      "LL-MANET-Routers" link-local multicast address defined in
      [RFC5498].

   o  Collect messages (possibly from multiple protocols) for the same
      local interface and destination, into packets to be sent one
      logical hop, and to send packets using the MANET UDP port or IP
      protocol defined in [RFC5498].

   o  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), this is the
   responsibility of the protocols.  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.

Top      ToC       Page 8 
   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) because it specifies and
   mandates constraints on the use of [RFC5444] that, if not followed,
   make 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 is applicable (see Section 3).
   In a few circumstances, operation of [RFC5444] is modified.  These
   are all circumstances that do not occur in its main and current uses,
   specifically by [RFC6130] and [RFC7181] (that might already include
   the requirement, particularly through [RFC7188]).  That such
   modifying cases are an update to [RFC5444] is explicitly indicated in
   this specification.

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.

   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 therein.

Top      ToC       Page 9 
   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 does not specify a protocol but documents constraints
   on how to design protocols that use the generic packet/message format
   defined in [RFC5444] that, if not followed, makes forms of extensions
   of those protocols impossible, impedes the ability to generate
   efficient (small) messages, or makes desirable forms of generic
   parsers impossible.  The use of the [RFC5444] format is mandated by
   [RFC5498] for all protocols running over the MANET protocol and port,
   defined therein.  Thus, 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 as to where to put information
   for transmission:

   o  in a TLV to be added to the Packet Header;

   o  in a message of a type owned by another protocol; or

   o  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

Top      ToC       Page 10 
   if the information is expected to have a wider application than a
   single protocol.  A protocol can also request that the Packet Header
   include Packet Sequence Numbers but does not 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 be simply an update of the protocol
   (the third case) or be a new protocol that also updates another
   protocol (the second case).  An example of the latter is that OLSRv2
   [RFC7181] is a protocol that also extends the HELLO message owned by
   NHDP [RFC6130]; it is thus 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 to be possible,
   and some of the rules in this document (in Sections 4.6 and 4.8,
   specifically) are to help facilitate that.

4.2.  Message and TLV Type Allocation

   Protocols SHOULD be conservative in the number of new Message Types
   that they require, as the total available number of allocatable
   Message Types is only 224.  Protocol design SHOULD consider whether
   different functions can be implemented by differences in TLVs carried
   in the same Message Type rather than using multiple Message Types.

   The TLV Type space, although greater than the Message Type space,
   SHOULD also be used efficiently.  The Full Type of a TLV occupies two
   octets; thus, there are many more available TLV Full Types than there
   are Message Types.  However, in some cases (currently LINK_METRIC
   from [RFC7181] and ICV and TIMESTAMP from [RFC7182], all in the
   global TLV Type space), a TLV Type with a complete set of 256 TLV
   Full Types is defined (but not necessarily allocated).

   Each Message Type has an associated block of Message-Type-specific
   TLV Types (128 to 233, each with 256 type extensions) both for
   Address Block TLV Types and Message TLV Types.  TLV Types from within
   these blocks SHOULD be used in preference to the Message-Type-
   independent Message TLV Types (0 to 127, each with 256 type
   extensions) when a TLV is specific to a message.

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

Top      ToC       Page 11 
4.3.  Message Recognition

   A message contains a Message Header and a Message Body; note that the
   Message TLV Block is considered part of the latter.  The Message
   Header contains information whose primary purpose is to decide
   whether to process the message and whether to forward the message.

   A protocol might need to recognize whether a message, especially a
   flooded message, is one that it has previously received (for example,
   to determine whether to process and/or forward it, or to discard it).
   A message can be recognized as one that has been previously seen if
   it contains sufficient information in its Message Header.  A message
   MUST be so recognized by the combination of its Message Type,
   Originator Address, and Message Sequence Number.  The inclusion of
   Message Type allows each protocol to manage its own Message Sequence
   Numbers and also allows for the possibility that different Message
   Types can have greatly differing transmission rates.  As an example
   of such use, [RFC7181] contains a general purpose process for
   managing processing and forwarding decisions, although specifically
   for use with MPR flooding.  (Blind flooding can be handled similarly
   by assuming that all other routers are MPR selectors; it is not
   necessary in this case to differentiate between interfaces on which a
   message is received.)

   Most protocol information is thus contained in the Message Body.  A
   model of how such 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.  Note that 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
   is established by the router and protocol generating the message.

4.4.  Message Multiplexing and Packets

   The multiplexer has to handle message multiplexing into packets and
   the transmission of said packets, as well as packet reception and
   demultiplexing into messages.  The multiplexer and the protocols that
   use it are subject to the following rules.

Top      ToC       Page 12 
4.4.1.  Packet Transmission

   Packets are formed for transmission through the following steps:

   o  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.

   o  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; the destination is therefore either a link-local
      multicast address (if the packet is being multicast) or the
      address of the neighbor interface to which the packet is sent.

   o  The owning protocol MAY request that messages are kept together in
      a packet; 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 from the same or
      different protocols, provided that in so doing 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 will not
      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; this is generally considered
      undesirable, especially when transmission can be unreliable.

   o  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.

   o  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

Top      ToC       Page 13 
      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).

   o  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:

   o  The Packet Header and the organization into the messages that it
      contains MUST be verified by the demultiplexer.

   o  The packet and/or the messages it contains MAY also be verified by
      an extension to the demultiplexer, such as [RFC7182].

   o  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.

   o  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.

   o  The owning protocol MUST verify each message for correctness; it
      MUST allow any extending protocol(s) to also contribute to this
      verification.

Top      ToC       Page 14 
   o  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.

   o  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 between the multiplexer and the protocols
   in each direction, the following additional information (summarized
   from other sections in this specification) can be exchanged.

   o  The packet source and destination addresses MUST be sent from the
      demultiplexer to the protocol.

   o  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 only report the Packet
      Sequence Number, on request.)

   o  A protocol MAY require that all outgoing packets contain a Packet
      Sequence Number.

   o  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].

   o  A request to keep messages together in one packet MAY be sent from
      protocol to multiplexer.

   o  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.

Top      ToC       Page 15 
4.5.  Messages, Addresses, and Attributes

   The information in a Message Body, including Message TLVs and Address
   Block TLVs, consists of:

   o  Attributes of the message, in which each attribute consists of a
      Full Type, a length, and a Value (of that length).

   o  A set of addresses, which are carried in one or more Address
      Blocks.

   o  Attributes of each address, in which each attribute consists of a
      Full Type, a length, and a Value (of that length).

   Attributes are carried in TLVs.  For Message TLVs, the mapping from
   TLV to attribute is one to one.  For Address Block TLVs, the mapping
   from TLV to attribute is one to many: one TLV can carry attributes
   for multiple addresses, but only one attribute per address.
   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 - i.e., when more than one
   Packet TLV of the same TLV Full Type is included in the same Packet
   Header, when more than one Message TLV of the same TLV Full Type is
   included 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.  It is RECOMMENDED that when defining a new TLV Full Type, a
   rule of the following form is adopted.

   o  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.

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

Top      ToC       Page 16 
4.6.  Addresses Require Attributes

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

   o  The simple presence of an address.

   o  The ordering of addresses in an Address Block.

   o  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.

   In addition, rules for the extensibility of OLSRv2 and NHDP are
   described in [RFC7188].  This specification extends their
   applicability to other uses of [RFC5444].

   These rules are:

   o  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.

   o  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.

   o  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.

   o  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.

Top      ToC       Page 17 
   Assigning a meaning to the presence, absence, or location of an
   address would reduce the extensibility of the protocol, prevent the
   approach to information representation described in Appendix A, and
   reduce the options available for message optimization described in
   Section 6.

   To consider 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.

   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.

   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.

Top      ToC       Page 18 
   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]).

   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.

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.

   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).

   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.)

Top      ToC       Page 19 
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:

   o  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).

   o  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.



(page 19 continued on part 2)

Next Section