Mobile Ad hoc Networking (MANET)                              T. Clausen
Internet-Draft                          LIX, Ecole Polytechnique, France
Intended status: Standards Track                             C. Dearlove
Expires: September 8, December 26, 2008               BAE Systems Advanced Technology
                                                                  Centre
                                                                 J. Dean
                                               Naval Research Laboratory
                                                                C. Adjih
                                                      INRIA Rocquencourt
                                                           March 7,
                                                           June 24, 2008

                Generalized MANET Packet/Message Format
                      draft-ietf-manet-packetbb-12
                      draft-ietf-manet-packetbb-13

Status of This Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 8, December 26, 2008.

Abstract

   This document specifies a packet format capable of carrying multiple
   messages that may be used by mobile ad hoc network routing and
   signaling protocols.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  Notation and Terminology . . . . . . . . . . . . . . . . . . .  4
     2.1.  Notation . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  7  5
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  8  7
   5.  Syntactical Specification  . . . . . . . . . . . . . . . . . .  9  7
     5.1.  Packets  . . . . . . . . . . . . . . . . . . . . . . . . .  9  7
     5.2.  Messages . . . . . . . . . . . . . . . . . . . . . . . . . 11  8
     5.3.  Address Blocks . . . . . . . . . . . . . . . . . . . . . . 13 10
     5.4.  TLVs and TLV Blocks  . . . . . . . . . . . . . . . . . . . 16 13
       5.4.1.  TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 16 14
       5.4.2.  TLV Inclusion and Constraints  . . . . . . . . . . . . 19 17
     5.5.  Malformed Elements . . . . . . . . . . . . . . . . . . . . 20 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21 18
     6.1.  Expert Review: Evaluation Guidelines . . . . . . . . . . . 18
     6.2.  Message Types  . . . . . . . . . . . . . . . . . . . . . . 21
     6.2.
       6.2.1.  Message Type Specific TLV Registry Creation  . . . . . 21
     6.3.  Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 21
     6.3.
       6.3.1.  Packet TLV Type Extension Registry Creation  . . . . . 21
     6.4.  Message TLV Types  . . . . . . . . . . . . . . . . . . . . 21
       6.4.1.  Message TLV Type Extension Registry Creation . . . . . 22
     6.4.
     6.5.  Address Block TLV Types  . . . . . . . . . . . . . . . . . 22
       6.5.1.  Address Block TLV Type Extension Registry Creation . . 23
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24 23
     7.1.  Authentication and Integrity Suggestions . . . . . . . . . 24
     7.2.  Confidentiality Suggestions  . . . . . . . . . . . . . . . 24
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 25 26
   Appendix A.  Intended Usage  . . . . . . . . . . . . . . . . . . . 26
   Appendix B.  Compatibility Requirements for Future Versions  Multiplexing and Demultiplexing . . . . . . . . . . . 27
   Appendix C.  Examples  . . . . . . . . . . . . . . . . . . . . . . 28
     C.1.  Address Block Examples . . . . . . . . . . . . . . . . . . 28
     C.2.  TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 30
   Appendix D.  Illustrations . . . . . . . . . . . . . . . . . . . . 33 32
     D.1.  Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     D.2.  Message  . . . . . . . . . . . . . . . . . . . . . . . . . 40 36
     D.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 46 42
     D.4.  Address Block  . . . . . . . . . . . . . . . . . . . . . . 47 43
     D.5.  TLV Block  . . . . . . . . . . . . . . . . . . . . . . . . 54 50
     D.6.  TLV  . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 51
   Appendix E.  Complete Example  . . . . . . . . . . . . . . . . . . 60 56
   Appendix F.  Contributors  . . . . . . . . . . . . . . . . . . . . 62 57
   Appendix G.  Acknowledgements  Acknowledgments . . . . . . . . . . . . . . . . . . . 63 58

1.  Introduction

   This document specifies the syntax of a general purpose packet format
   capable of designed to
   carrying multiple messages for information exchange between MANET
   (Mobile Ad hoc NETwork) routers.  Messages consist of a message
   header, which is designed for control of message dissemination, and a
   message body, which contains protocol information.  Only the syntax
   of the packet and messages is specified.  All syntactical entities,
   including packets and messages, are specified using a regular expressions.
   expression derived notation.

   This document specifies:

   o  A packet format, allowing zero or more messages to be contained
      within a single transmission, and optionally including a packet
      header. transmission.  A packet with zero messages may be
      sent in case the only information to exchange is contained in the
      packet header.

   o  A message format, where a message is composed of a message header
      and a message body.

   o  A message header format, which contains information which may be
      sufficient to allow a protocol using this specification to make
      processing and forwarding decisions.

   o  A message body format, containing attributes associated with the
      message or the originator of the message, as well as blocks of
      addresses, or address prefixes, with associated attributes.

   o  An address block format, where an address block represents sets of
      addresses, or address prefixes, in a compact (compressed) form. form with aggregated
      addresses.

   o  A generalized type-length-value (TLV) format representing
      attributes.  Each TLV can be associated with a packet, a message,
      or one or more addresses or address prefixes in a single address
      block.  Multiple TLVs can be included and each associated with a
      packet, a message, and with the same, different or one or more overlapping
      sets of addresses or address prefixes.

   The specification has been explicitly designed with the following
   properties, listed in no particular order, in mind:

   Parsing logic  - the regular expression derived notation used in this
      specification facilitates generic, protocol independent, parsing
      logic.

   Extensibility  - packets and messages defined by a protocol using
      this specification are extensible through by defining new message types
      and new TLVs.  Existing protocol specifications  Protocols using this specification will be able to
      correctly identify and skip such new message types and TLVs, while
      correctly parsing the remainder of the packet and message.

   Efficiency  - when reported addresses share common bit sequences
      (e.g. address prefixes or IPv6 interface identifiers) the address
      block representation allows for a compact representation.  Compact
      message headers are ensured through permitting inclusion of only
      required message header elements, unless indicated otherwise. elements.  The structure of packet and
      message encoding allows parsing, verifying, and identifying
      individual elements in a single pass.

   Separation of forwarding and processing  - a protocol using this
      specification can be designed such that duplicate detection and
      controlled scope message forwarding decisions can be made using
      information contained in the message header, without processing
      the message body.

2.  Terminology and  Notation and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
   [RFC2119].

   Additionally, this document uses the following terminology:

   Packet  - The top level entity notation in this specification.  A packet
      contains zero or more messages, Section 2.1, and may contain a packet header.

   Message  - The fundamental entity carrying protocol information, in the form of address objects and TLVs.

   Address  - A number of octets of the same length as the source IP
      address
   terminology in the IP datagram carrying the packet.  The meaning of an
      address is defined by the protocol using this specification.

   Address Prefix  - An address plus a prefix length, with the prefix
      length being Section 2.2.

2.1.  Notation

   This specification uses a number of address bits measured from the left/most
      significant end derivative of the address.

   Address Object  - Either an address, regular expression
   language from [SingleUNIX], [POSIX] or an address prefix, as
      specified in an address block in this specification.

   TLV  - A Type-Length-Value structure.  This is a generic way in which
      an attribute can be represented and correctly parsed, without the
      parser having to understand [ECMAScript], using only the attribute.
   following notation:

   Element  - A group of any number of consecutive bits which, together,
      forms a syntactic entity defined in the regular expression
      specification, entity, represented using the notation <foo>.

   <foo>  - If <foo> is an 8 or 16 bit unsigned integer field then <foo> is also
      used to represent the value of that field.

   bar  - A variable, usually obtained through calculations based on the
      value(s) of element(s).  Variables are introduced into the
      specification solely as a means to clarify the description.

   := - Indicates that the element or variable on the left hand side is
      defined as the expression on the right hand side.

   {<element1><element2>}

   (<element1><element2>)  - Indicates a grouping of the elements
      enclosed by the braces. parentheses.

   ?  - Zero or one occurrences of the preceding element or group.

   *  - Zero or more occurrences of the preceding element or group.

   address-length  - A variable whose value is the length of an address
      in octets, it is 4 if using IPv4, or 16 if using IPv6.

3.  Applicability Statement

2.2.  Terminology

   This specification describes document uses the following terminology:

   Packet  - The top level entity in this specification.  A packet
      contains a generic packet format capable of
   carrying multiple messages, for carrying MANET routing protocol
   signals.  The specification has been inspired by header and extended from
   that used by OLSR (The Optimized Link State Routing protocol)
   [RFC3626]. zero or more messages.

   Message  - The specification is designed with IP (IPv4/IPv6) fundamental entity carrying protocol information, in mind.  All
   addresses within a control message are assumed to be
      the form of address objects and TLVs.

   Address  - A number of octets of the same
   size, deduced from IP.  In length as the case source IP
      address in the IP datagram carrying the packet.  The meaning of mixed IPv6 and IPv4 addresses,
   IPv4 addresses can be represented as IPv4-mapped IPv6 addresses as
   specified in [RFC4291].

   The messages an
      address is defined by this specification are designed to carry
   MANET routing protocol signals between MANET routers.  This
   specification includes elements which can support limited diffusion
   (flooding), as well as being usable for point to point delivery of
   MANET routing the protocol signals in a multi-hop network.

   The packets defined by using this specification are designed to carry specification.

   Address Prefix  - An address plus a prefix length, with the prefix
      length being a number of MANET routing protocol messages in a single transmission.
   The packets may be unicast address bits measured from the left/most
      significant end of the address.

   Address Object  - Either an address, or multicast, and may be transmitted an address prefix, as
   appropriate to the MANET routing protocol using
      specified in an address block in this specification.

   TLV  - A Type-Length-Value structure.  This specification is particularly appropriate for extensible MANET
   routing protocols.  It offers external extensibility in the form of
   new message types.  It offers internal extensibility a generic way in the form of
   TLVs, which may
      an attribute can be added to existing message types.

   A MANET routing protocol using the multi-message packet format
   defined by this specification MAY constrain represented and correctly parsed, without the syntax (for example
   requiring a specific set of message header fields) that
      parser having to understand the protocol
   will employ.

4.  Protocol Overview and Functioning attribute.

3.  Applicability Statement

   This specification does not describe a protocol.  It describes a generic packet format, which may be used designed for
   use by any mobile ad hoc network MANET routing
   or other protocol.

5.  Syntactical Specification

   This section provides syntactical protocols.  The specification of a packet,
   represented has been inspired
   by the element <packet> and the elements extended from which it is
   composed.  The specification is given in the form that used by OLSR (The Optimized Link State
   Routing protocol) [RFC3626].

   MANETs are, commonly though not exclusively, characterized as being
   able to run over wireless network interfaces of regular
   expressions.  Illustrations limited to moderate
   capacity.  MANETs are therefore less tolerant of specified elements wasted transmitted
   octets than are given in
   Appendix D. most wired networks.  This format uses network byte order (most significant octet first)
   for all fields.

5.1.  Packets

   <packet> is defined by:

       <packet> := <pkt-header>?
                   <message>*

   where <message> is as defined in Section 5.2.  Successful parsing specification thus
   represents a tradeoff between sometimes competing attributes,
   specifically efficiency, extensibility, and ease of use.

   Efficiency is
   terminated when all octets (defined using the variable pkt-size
   below) are used.  A supported by reducing packet MUST NOT be empty, that is size and by allowing
   multiple disjoint messages in a single packet.  Reduced packet MUST
   contain either a <pkt-header> or at least one <message>.

   <pkt-header> is defined by:

       <pkt-header> := <zero>
                       <pkt-semantics>
                       <pkt-version>?
                       <pkt-size>?
                       <pkt-seq-num>?
                       <tlv-block>?

   where:

   <zero> size
   is an 8 bit field with all bits cleared ('0').  This field
      serves to identify that the primarily supported by address aggregation, optional packet starts with a <pkt-header>.

   <pkt-semantics>  is an 8 bit field, specifying the composition of the
      <pkt-header>:

      bit 0 (phasversion):  If cleared ('0'), then <pkt-version> is not
         included and
   message header fields, and optional fields in the <pkt-header>.  If set ('1'), then <pkt-version>
         is included address blocks and
   TLVs.  Supporting multi-message packets allows a reduction in the <pkt-header>.

      bit 1 (phassize):  If cleared ('0'), then <pkt-size>
   number of packets, each of which can incur significant bandwidth
   costs from transport, network and lower layers.

   This specification provides both external and internal extensibility.
   External extensibility is not
         included in supported by the <pkt-header>.  If set ('1'), then <pkt-size> ability to add packet TLVs
   and to define new message types.  Internal extensibility is
         included in supported
   by the <pkt-header>.

      bit 2 (phasseqnum):  If cleared ('0'), then <pkt-seq-num> is not
         included in the <pkt-header>.  If set ('1'), then <pkt-seq-num>
         is included in the <pkt-header>.

      bit 3 (phastlv):  If cleared ('0'), then <tlv-block> is not
         included in the <pkt-header>.  If set ('1'), then <tlv-block>
         is included in the <pkt-header>.

      bit 4 (pnouniord):  If cleared ('0'), then the packet TLV block
         MUST conform ability to the constraints in Section 5.4.2.  If set
         ('1'), then the packet TLV add message TLVs and address block is not subject TLVs to existing
   messages.  Protocols can define new TLV types, and hence the
         constraints in contents
   of their value fields (see Section 5.4.2.  Additional constraints MAY be
         imposed by a protocol using 6.1), and new message types.
   Protocols can also reuse message and TLV type definitions from other
   protocols which also use this specification.

      bits 5-7:  Are RESERVED,

   This specification aims at being sufficiently expressive and SHOULD each flexible
   to be cleared ('0') on
         transmission, able to accommodate both different classes of MANET routing
   protocols (e.g. proactive, reactive and SHOULD hybrid routing protocols), as
   well as extensions thereto.  Having a common packet and message
   format, and a common way of representing IP addresses and associated
   attributes, allows generic parsing code to be ignored on reception.

   <pkt-version>  is omitted if the phasversion bit is cleared ('0'),
      otherwise is an 8 bit unsigned integer field, specifying the
      version developed, regardless
   of this specification.

   <pkt-size>  is omitted if the phassize bit is cleared ('0'),
      otherwise is a 16 bit unsigned integer field, specifying algorithm used by the
      number routing protocol.

   All addresses within a message are assumed to be of octets that make up the <packet>.

   <pkt-seq-num>  is omitted if same size,
   deduced from the phasseqnum bit is cleared ('0'),
      otherwise is a 16 bit unsigned field, specifying a packet sequence
      number.

   <tlv-block>  is omitted if IP header.  In the phastlv bit is cleared ('0'), case of mixed IPv6 and is
      otherwise IPv4
   addresses, IPv4 addresses can be represented as defined IPv4-mapped IPv6
   addresses as specified in Section 5.4.

   Note that since message type zero is not used (see Section 6), the
   presence [RFC4291].  Packets may be unicast or
   multicast, and may use any appropriate transport protocol, or absence none.

   The messages defined by this specification are designed to carry
   MANET routing protocol signaling between MANET routers.  This
   specification includes elements which can support limited diffusion
   (flooding), as well as being usable for point to point delivery of
   MANET routing protocol signaling in a multi-hop network.

   A MANET routing protocol using the packet header can be determined format defined by
   inspecting this
   specification can constrain the first octet syntax (for example requiring a
   specific set of message header fields) that the packet.

   pkt-version  is a variable, defined to equal <pkt-version> if
      present, or zero (0) otherwise. pkt-version MUST protocol will employ.
   Protocols with such restrictions need not be zero able to parse all
   possible packet structures as defined by this document but must be
   coherent in
      accordance with this version of this specification.  See
      Appendix B.

   pkt-size  is a variable, defined to equal <pkt-size> if present, or
      the size packet generation and reception of the payload packets of the network or transport which they
   define.  If a protocol
      employed otherwise.  (If not present, and specifies which elements are included, then
   direct indexing of the payload size appropriate fields is
      unknown, then possible, dependant on
   the syntax restrictions imposed by the protocol.  Such protocols may
   have more limited extensibility.

4.  Protocol Overview and Functioning

   This specification does not describe a protocol.  It describes a
   packet cannot format, which may be parsed, and is considered
      malformed.)

5.2.  Messages

   Information is carried through messages.  Messages contain:

   o  A message header.

   o  A message TLV block that contains zero or more TLVs, associated
      with used by any mobile ad hoc network routing
   protocol.

5.  Syntactical Specification

   This section provides syntactical specification of a packet,
   represented by the whole message.

   o  Zero or more address blocks, each containing one or more address
      objects.

   o  An address TLV block, containing zero or more TLVs, following each
      address block.

   <message> element <packet> and the elements from which it is
   composed.  The specification is given using the notation in
   Section 2.1.  Illustrations of specified elements are given in
   Appendix D.

   This format uses network byte order (most significant octet first)
   for all fields.  The most significant bit in an octet is numbered bit
   0, and the least significant bit of an octet is numbered bit 7
   [Stevens].

5.1.  Packets

   <packet> is defined by:

       <message>    := <msg-header>
                       <tlv-block>
                       {<addr-block><tlv-block>}*

       <msg-header>

       <packet> := <msg-type>
                       <msg-semantics>
                       <msg-version>?
                       <msg-size>
                       <msg-orig-addr>?
                       <msg-hop-limit>?
                       <msg-hop-count>?
                       <msg-seq-num>?

   where:

   <tlv-block> <pkt-header>
                   <message>*

   where <message> is as defined in Section 5.4.

   <addr-block> 5.2.  Successful parsing is as
   terminated when all octets of the packet (as defined in Section 5.3.

   <msg-type> by the datagram
   containing the packet) are used.

   <pkt-header> is an 8 defined by:

       <pkt-header> := <version>
                       <pkt-flags>
                       <pkt-seq-num>?
                       <tlv-block>?

   where:

   <version>  is a 4 bit unsigned integer field, specifying field and specifies the type
      version of the message.  A type with all bits cleared ('0') MUST NOT be
      used.

   <msg-semantics> specification on which the packet and the contained
      messages are constructed.  This document specifies version 0.

   <pkt-flags>  is an 8 a 4 bit field, specifying the interpretation of the
      remainder of the message packet header:

      bit 0 (mhasversion): (phasseqnum):  If cleared ('0'), then <msg-version> <pkt-seq-num> is not
         included in the <msg-header>. <pkt-header>.  If set ('1'), then <msg-version> <pkt-seq-num>
         is included in the <msg-header>. <pkt-header>.

      bit 1 (mhasorig): (phastlv):  If cleared ('0'), then <msg-orig-addr> <tlv-block> is not
         included in the <msg-header>. <pkt-header>.  If set ('1'), then <msg-orig-
         addr> <tlv-block>
         is included in the <msg-header>. <pkt-header>.

      bit 2 (mhashoplimit): (pnouniord):  If cleared ('0'), then <msg-hop-limit> is
         not included in the <msg-header>.  If set ('1'), then <msg-hop-
         limit> is included in the <msg-header>.

      bit 3 (mhashopcount):  If cleared ('0'), then <msg-hop-count> is
         not included in the <msg-header>.  If set ('1'), then <msg-hop-
         count> is included in the <msg-header>

      bit 4 (mhasseqnum):  If cleared ('0'), then <msg-seq-num> is not
         included in the <msg-header>.  If set ('1'), then <msg-seq-num>
         is included in the <msg-header>.

      bit 5 (mistypedep):  If cleared ('0'), then the message sequence
         number in the message is type-independent.  If set ('1'), then
         the message sequence number contained in the message is type
         dependent (the message originator maintains a sequence number
         specific to <msg-type>).  This bit MUST be cleared ('0') if the
         mhasorig bit is cleared ('0').

      bit 6 (mnouniord):  If cleared ('0'), then the message packet TLV block
         and all address TLV blocks in the message
         MUST conform to the constraints in Section 5.4.2.  If set
         ('1'), then the message packet TLV block and all address TLV blocks in the message are is not subject to the
         constraints in Section 5.4.2.  Additional constraints MAY be
         imposed by a protocol using this specification.

      bit 7: 3:  Is RESERVED, and SHOULD be cleared ('0') on transmission,
         and SHOULD be ignored on reception.

   <msg-version>

   <pkt-seq-num>  is omitted if the mhasversion bit phasseqnum pkt-flag is cleared
      ('0'), otherwise is an 8 bit unsigned integer field, specifying the
      version of this specification.

   <msg-size>  is a 16 bit unsigned integer field, specifying the number
      of octets that make up the <message>

   <msg-orig-addr> a
      packet sequence number.

   <tlv-block>  is omitted if the mhasorig bit phastlv flag is cleared ('0'),
      otherwise and is an identifier with length equal to address-length,
      which can serve
      otherwise as defined in Section 5.4.

5.2.  Messages

   Packets may, in addition to uniquely identify the node packet header, contain one or more
   messages.  Messages contain:

   o  A message header.

   o  A message TLV block that originated contains zero or more TLVs, associated
      with the whole message.

   <msg-hop-limit>  is omitted if the mhashoplimit bit is cleared ('0'),
      otherwise is an 8 bit unsigned integer field, which can contain
      the maximum number of hops that the message should

   o  Zero or more address blocks, each containing one or more address
      objects.

   o  An address TLV block, containing zero or more TLVs, following each
      address block, through which addresses can be further
      transmitted.

   <msg-hop-count> associated with
      additional attributes.

   <message> is omitted if the mhashopcount bit defined by:

       <message>    := <msg-header>
                       <tlv-block>
                       (<addr-block><tlv-block>)*

       <msg-header> := <msg-type>
                       <msg-flags>
                       <msg-size>
                       <msg-orig-addr>?
                       <msg-hop-limit>?
                       <msg-hop-count>?
                       <msg-seq-num>?

   where:

   <tlv-block>  is cleared ('0'),
      otherwise as defined in Section 5.4.

   <addr-block>  is as defined in Section 5.3.

   <msg-type>  is an 8 bit unsigned integer field, which can contain specifying the number type
      of the message.

   <msg-flags>  is an 8 bit field, specifying the interpretation of the
      remainder of hops that the message has traveled.

   <msg-seq-num> header:

      bit 0 (mhasorig):  If cleared ('0'), then <msg-orig-addr> is omitted if not
         included in the mhasseqnum <msg-header>.  If set ('1'), then <msg-orig-
         addr> is included in the <msg-header>.

      bit 1 (mhashoplimit):  If cleared ('0'), then <msg-hop-limit> is
         not included in the <msg-header>.  If set ('1'), then <msg-hop-
         limit> is included in the <msg-header>.

      bit 2 (mhashopcount):  If cleared ('0'),
      otherwise then <msg-hop-count> is a 16
         not included in the <msg-header>.  If set ('1'), then <msg-hop-
         count> is included in the <msg-header>.

      bit unsigned integer field, which can contain a 3 (mhasseqnum):  If cleared ('0'), then <msg-seq-num> is not
         included in the <msg-header>.  If set ('1'), then <msg-seq-num>
         is included in the <msg-header>.

      bit 4 (mistypedep):  If cleared ('0'), then the message sequence number, generated by
         number in the message's originator node.

   msg-version message is type-independent.  If set ('1'), then
         the message sequence number contained in the message is type
         dependent (the message originator maintains a variable, defined sequence number
         specific to equal <msg-version> if
      present, or to pkt-version otherwise. msg-version <msg-type>).  This msg-flag MUST be 0 (zero) cleared ('0')
         if the mhasorig msg-flag is cleared ('0').

      bit 5 (mnouniord):  If cleared ('0'), then the message TLV block
         and all address TLV blocks in the message MUST conform to be the
         constraints in accordance with this version of Section 5.4.2.  If set ('1'), then the message
         TLV block and all address TLV blocks in the message are not
         subject to the constraints in Section 5.4.2.  Additional
         constraints MAY be imposed by a protocol using this
         specification.  See
      Appendix B.

      bit 6-7:  Are RESERVED, and SHOULD each be cleared ('0') on
         transmission, and SHOULD be ignored on reception.

   <msg-size>  is a 16 bit unsigned integer field, specifying the number
      of octets that make up the <message>, including the <msg-header>.

   <msg-orig-addr>  is omitted if the mhasorig msg-flag is cleared
      ('0'), otherwise is an identifier with length equal to address-
      length, which can serve to uniquely identify the node that
      originated the message.

   <msg-hop-limit>  is omitted if the mhashoplimit msg-flag is cleared
      ('0'), otherwise is an 8 bit unsigned integer field, which can
      contain the maximum number of hops that the message should be
      further transmitted.

   <msg-hop-count>  is omitted if the mhashopcount msg-flag is cleared
      ('0'), otherwise is an 8 bit unsigned integer field, which can
      contain the number of hops that the message has traveled.

   <msg-seq-num>  is omitted if the mhasseqnum msg-flag is cleared
      ('0'), otherwise is a 16 bit unsigned integer field, which can
      contain a sequence number, generated by the message's originator
      node.

5.3.  Address Blocks

   An address block can specify one or more addresses.  It can also
   specify prefix lengths that can be applied to all addresses in the
   address block.  This allows an address block to specify either
   addresses or address prefixes.  A protocol may specify that an
   address with a maximum prefix length (equal to the address length, in
   bits) is considered to be an address, rather than a an address prefix,
   thus allowing an address block to contain a mixture of addresses and
   address prefixes.  The common term "address object" is used in this
   specification to cover both of these; note that an address object in
   an address block always includes the prefix length, if present.

   An address is specified as a sequence of address-length octets of the
   form head:mid:tail.  An address block contains an ordered set of
   addresses sharing the same head and tail,  There are no semantics associated with head, mid
   or tail; this representation is solely to allow aggregation of
   addresses, which often have common parts (e.g. common prefixes or
   multiple IPv6 addresses on the same interface).  An address block
   contains an ordered set of addresses all sharing the same head and
   the same tail, but having individual mids.  Independently, head and
   tail may be empty, allowing for representation of address objects
   which do not have common heads or common tails.  Detailed examples of
   address blocks are included in Appendix C.1.

   An address block can specify address prefixes:

   o  with a single prefix length for all address prefixes, prefixes; OR

   o  with a prefix length for each address prefix.

   <address-block> is defined by:

       <address-block> := <num-addr>
                          <addr-semantics>
                          {<head-length><head>?}?
                          {<tail-length><tail>?}?
                          <addr-flags>
                          (<head-length><head>?)?
                          (<tail-length><tail>?)?
                          <mid>*
                          <prefix-length>*

   where:

   <num-addr>  is an 8 bit unsigned integer field containing the number
      of addresses represented in the address block, which MUST NOT be
      zero.

   <addr-semantics>

   <addr-flags>  is an 8 bit field specifying the interpretation of the
      remainder of the address block:

      bit 0 (ahashead):  If cleared ('0'), then <head-length> and <head>
         are not included in the <address-block>.  If set ('1'), then
         <head-length> is included in the <address-block>, and <head> is
         included in the <address-block> unless <head-length> is zero.

      bit 1 (ahasfulltail) and bit 2 (ahaszerotail):  Are interpreted
         according to Table 1.  A combination not shown in that table
         MUST NOT be used.

      bit 3 (ahassingleprelen) and bit 4 (ahasmultiprelen):  Are
         interpreted according to Table 2.  A combination not shown in
         that table MUST NOT be used.

      bits 5-7:  Are RESERVED, and SHOULD each be cleared ('0') on
         transmission, and SHOULD be ignored on reception.

   +--------------+--------------+---------------+---------------------+
   | ahasfulltail | ahaszerotail | <tail-length> |        <tail>       |
   +--------------+--------------+---------------+---------------------+
   |       0      |       0      |  not included |     not included    |
   |              |              |               |                     |
   |       1      |       0      |    included   |   included unless   |
   |              |              |               |   <tail-length> is  |
   |              |              |               |         zero        |
   |              |              |               |                     |
   |       0      |       1      |    included   |     not included    |
   +--------------+--------------+---------------+---------------------+

    Table 1: Interpretation of the ahasfulltail and ahaszerotail bits addr-
                                   flags

   +------------+-----------+------------------+-----------------------+
   | ahassingle | ahasmulti |     number of    |  prefix length of the |
   |   prelen   |   prelen  |  <prefix-length> |  nth address prefix,  |
   |            |           |      fields      |        in bits        |
   +------------+-----------+------------------+-----------------------+
   |      0     |     0     |         0        |   8 * address-length  |
   |            |           |                  |                       |
   |      1     |     0     |         1        |    <prefix-length>    |
   |            |           |                  |                       |
   |      0     |     1     |    <num-addr>    |  nth <prefix-length>  |
   +------------+-----------+------------------+-----------------------+

    Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen
                                   bits
                                addr-flags

   <head-length>  if present is an 8 bit unsigned integer field, which
      contains the number of octets in the head of all of the addresses. addresses
      in the address block.

   head-length  is a variable, defined to equal <head-length> if
      present, or 0 otherwise.

   <head>  is omitted if head-length is equal to 0, otherwise it is a
      field of the head-length leftmost octets of common to all the addresses.
      addresses in the address block.

   <tail-length>  if present is an 8 bit unsigned integer field, which
      contains the number of octets in the tail of all of the addresses. addresses
      in the address block.

   tail-length  is a variable, defined to equal <tail-length> if
      present, or 0 otherwise.

   <tail>  is omitted if tail-length is equal to 0 0, or if the
      ahaszerotail bit is set ('1'), otherwise it is a field of the
      tail-length rightmost octets of common to all the addresses. addresses in the
      address block.  If the ahaszerotail bit is set ('1') then the
      tail-length rightmost octets of all the addresses in the address
      block are all 0.

   mid-length  is a variable, which MUST be non-negative, defined by:

      *  mid-length := address-length - head-length - tail-length

   <mid>  is omitted if mid-length is equal to 0, otherwise each <mid>
      is a field of length mid-length octets, representing the mid of
      the corresponding address in the address block.  When not omitted,
      an address block contains exactly <num-addr> <mid> fields.

   <prefix-length>  is an 8 bit unsigned integer field containing the
      length, in bits, of the prefix length of an address prefix.  If the ahassingleprelen bit
      addr-flag is set ('1') then a single <prefix-
      length> <prefix-length> field is
      included, which contains the prefix length of all addresses in the
      address block.  If the ahasmultiprelen bit addr-flag is set ('1') then each
      of the
      <num-addr> <prefix-length> fields are included, each of which
      contains the prefix length of the corresponding address prefix in
      the address block (in the same order).  Otherwise no <prefix-length> <prefix-
      length> fields are present; each address object can be considered
      to have a prefix length equal to 8 * address-length bits.  The
      address block is malformed if any <prefix-length> element has a
      value greater than 8 * address-length.

5.4.  TLVs and TLV Blocks

   A TLV block is defined by:

       <tlv-block> := <tlvs-length>
                      <tlv>*

   where:

   <tlvs-length>  is allows association of an arbitrary attribute with a 16 bit unsigned message or
   a packet, or with a single address or a contiguous set of addresses
   in an address block.  The attribute (value) is made up from an
   integer field, which contains the
      total number of octets consecutive octets.  Different attributes have
   different types; attributes which are unknown when parsing can be
   skipped.

   TLVs are grouped in TLV blocks, with all of TLVs within a TLV block
   associating attributes with either the packet (for the TLV block in
   the packet header), the message (for the TLV block immediately
   following the message header) or to addresses in the immediately
   preceding address block.  Individual TLVs in a TLV block immediately
   following an address block can associate attributes to a single
   address, a range of addresses or all addresses in that address block.
   When associating an attribute with more than one address, a TLV can
   include one value for all addresses, or one value per address.
   Detailed examples of TLVs are included in Appendix C.2.

   A TLV block is defined by:

       <tlv-block> := <tlvs-length>
                      <tlv>*

   where:

   <tlvs-length>  is a 16 bit unsigned integer field, which contains the
      total number of octets in all of the immediately following <tlv>
      elements.
      elements (<tlvs-length> not included).

   <tlv>  is as defined in Section 5.4.1.

5.4.1.  TLVs

   There are three kinds of TLV, each represented by an element <tlv>:

   o  A packet TLV, included in the packet TLV block in a packet header.

   o  A message TLV, included in the message TLV block in a message,
      before the first any address block. blocks.

   o  An address block TLV, included in an address TLV block following
      an address block.  An address block TLV applies to:

      *  all address objects in the address block; OR

      *  any continuous sequence of address objects in the address
         block; OR

      *  a single address object in the address block.

   <tlv> is defined by:

       <tlv> := <tlv-type>
                <tlv-semantics>
                <tlv-flags>
                <tlv-type-ext>?
                {<index-start><index-stop>?}?
                {<length><value>?}?
                (<index-start><index-stop>?)?
                (<length><value>?)?

   where:

   <tlv-type>  is an 8 bit unsigned integer field, specifying the type
      of the TLV, specific to the TLV kind (i.e. packet, message, or
      address block TLV).

   <tlv-semantics>

   <tlv-flags>  is an 8 bit field specifying the interpretation of the
      remainder of the TLV:

      bit 0 (thastypeext):  If cleared ('0'), then <tlv-type-ext> is not
         included in the <tlv>.  If set ('1'), then <tlv-type-ext> is
         included in the <tlv>.

      bit 1 (thassingleindex) and bit 2 (thasmultiindex):  Are
         interpreted according to Table 3.  A combination not shown in
         that table MUST NOT be used.  Both bits of these tlv-flags MUST be
         cleared ('0') in packet and message TLVs.

      bit 3 (thasvalue) and bit 4 (thasextlen):  Are interpreted
         according to Table 4.  A combination not shown in that table
         MUST NOT be used.

      bit 5 (tismultivalue):  This bit tlv-flag serves to specify how the
         <value> field is interpreted, as specified below.  This bit tlv-
         flag MUST be cleared ('0') in packet and message TLVs, if the
         thasmultiindex
         bit tlv-flag is cleared ('0'), or if the thasvalue bit
         tlv-flag is cleared ('0').

      bits 6-7:  Are RESERVED, and SHOULD each be cleared ('0') on
         transmission, and SHOULD be ignored on reception.

    +-----------------+----------------+---------------+--------------+
    | thassingleindex | thasmultiindex | <index-start> | <index-stop> |
    +-----------------+----------------+---------------+--------------+
    |        0        |        0       |  not included | not included |
    |                 |                |               |              |
    |        1        |        0       |    included   | not included |
    |                 |                |               |              |
    |        0        |        1       |    included   |   included   |
    +-----------------+----------------+---------------+--------------+

     Table 3: Interpretation of the thassingleindex and thasmultiindex
                                   bits
   +-----------+------------+-------------+----------------------------+
                                 tlv-flags

   +-----------+------------+--------------+---------------------------+
   | thasvalue | thasextlen |   <length>   |          <value>          |
   +-----------+------------+-------------+----------------------------+
   +-----------+------------+--------------+---------------------------+
   |     0     |      0     | not     |        not included |
   |           |            |        not included       |
   |
   |           |            |             |                            |
   |     1     |      0     |    8 bits    |  included unless <length> |
   |           |            |              |          is zero          |
   |           |            |             |                            |
   |     1     |      1     |    16 bits   |  included unless <length> |
   |           |            |              |          is zero          |
   +-----------+------------+-------------+----------------------------+
   +-----------+------------+--------------+---------------------------+

     Table 4: Interpretation of the thasvalue and thasextlen bits tlv-flags
   <tlv-type-ext>  is an 8 bit unsigned integer field, specifying an
      extension of the TLV type, specific to the TLV type and kind (i.e.
      packet, message, or address block TLV).

   tlv-type-ext  is a variable, defined to equal <tlv-type-ext> if
      present, or 0 otherwise.

   tlv-fulltype  is a variable, defined by:

      *  tlv-fulltype := 256 * <tlv-type> + tlv-type-ext; tlv-type-ext

   <index-start> and <index-stop>  when present, in an address block TLV
      only, are each an 8 bit unsigned integer field.

   index-start and index-stop  are variables, defined according to
      Table 5.  The variable end-index is defined as follows:

      *  For message and packet TLVs:

         +  end-index := 0

      *  For address block TLVs:

         +  end-index := <num-addr> - 1

      An address block TLV applies to the address objects from position
      index-start to position index-stop (inclusive) in the address
      block, where the first address object has position zero.

   +-----------------+----------------+----------------+---------------+
   | thassingleindex | thasmultiindex | index-start := | index-stop := |
   +-----------------+----------------+----------------+---------------+
   |        0        |        0       |        0       |   end-index   |
   |                 |                |                |               |
   |        1        |        0       |  <index-start> | <index-start> |
   |                 |                |                |               |
   |        0        |        1       |  <index-start> |  <index-stop> |
   +-----------------+----------------+----------------+---------------+

     Table 5: Interpretation of the thassingleindex and thasmultiindex
                                   bits
                                 tlv-flags

   number-values  is a variable, defined by:

      *  number-values := index-stop - index-start + 1
   <length>  is omitted or is an 8 or 16 bit unsigned integer field
      according to Table 4.  If the tismultivalue bit tlv-flag is set ('1')
      then <length> MUST be an integral multiple of number-values, and
      the variable single-length is defined by:

      *  single-length := <length> / number-values

      If the tismultivalue bit tlv-flag is cleared ('0'), then the variable
      single-length is defined by:

      *  single-length := <length>

   <value>  if present (see Table 4) is a field of length <length>
      octets.  In an address block TLV, <value> is associated with the
      address objects from positions index-start to index-stop,
      inclusive.  If the tismultivalue bit tlv-flag is cleared ('0') then
      the whole of this field is associated with each of the indicated
      address objects.  If the tismultivalue bit tlv-flag is set ('1') then
      this field is divided equally into number-values fields, each of
      length single-length octets octets, and these are associated, in order,
      with the indicated address objects.

5.4.2.  TLV Inclusion and Constraints

   A TLV associates an attribute with a packet, a message or one or more
   consecutive address objects in an address block.  The interpretation
   and processing of this attribute, and the relationship (including
   order of processing) between different attributes associated with the
   same entity MUST be defined by a protocol which uses this
   specification.

   If the appropriate semantics bit flags (pnouniord for a packet TLV block, mnouniord
   for a message TLV block or an address block TLV block) is clear are cleared
   ('0'), then the following constraints MUST be respected.  These bits flags
   MUST always be clear cleared ('0') unless a protocol using this
   specification defines otherwise.  Protocols SHOULD only define use of
   these bits flags when necessary, and then MUST indicate what constraints
   do apply if each of the indicated bits flags is set ('1'); each of these
   constraints SHOULD be retained unless otherwise necessary.

   o  TLVs in the same TLV block are sorted in non-descending tlv-
      fulltype order.

   o  Two or more address TLVs with the same tlv-fulltype in the same
      message are not associated with the same value of address object.

   o  TLVs with the same tlv-fulltype associated with the same address
      block are sorted in ascending index-start order.

   In addition, packet and message TLVs MUST be defined so as to
   indicate whether two such TLVs with the same tlv-fulltype are, or are
   not, allowed in the same packet or message TLV block, respectively.

   Note that the above constrains only the encoding of TLVs in a TLV
   block for transmission, and do specifically NOT mandate any given
   order of processing or interpretation by a protocol of the TLVs and
   the entities to which these are associated.

   Respecting the constraints above allows parsing and verification of a
   TLV block in a single pass and allows terminating the search for a
   TLV with a specific type without traversing the entire TLV block.

   The constraints on address block TLVs ensure that encoded information
   (entity-attributes) can be unambiguously decoded.

5.5.  Malformed Elements

   An element is malformed if it cannot be parsed according to its
   syntactical specification (including if there are insufficient octets
   available when a length is specified, in particular if there are
   fewer than pkt-size octets overall)
   available) or if a constraint (including, but not only, those
   specified in Section 5.4.2) specified as one which MUST be satisfied,
   is not.  A protocol using this specification MUST specify the action,
   or choice of actions, to be taken when a packet containing such
   elements is received.  Typical examples will include discarding any
   affected message(s), or discarding the complete packet.

6.  IANA Considerations

6.1.

   This document introduces four namespaces that require registration:
   Message Types, Packet TLV Types, Message TLV Types

   A new registry and Address Block
   TLV Types.  This section specifies IANA registries for message types must be created, these
   namespaces, and provides guidance to the Internet Assigned Numbers
   Authority regarding registrations in these namespaces.

   The following terms are used with initial
   assignments as specified the meanings defined in Table 6.

               +---------+---------------------------------+
               |   Type  | Description                     |
               +---------+---------------------------------+
               |    0    | MUST NOT be allocated.          |
               |         |                                 |
               | 128-255 | Reserved for private/local use. |
               +---------+---------------------------------+

                          Table 6: Message Types

   Future values [BCP26]:
   "Namespace", "Assigned Value", "Registration", "Unassigned",
   "Reserved", "Hierarchical Allocation", "Designated Expert".

   The following policies are used with the meanings defined in [BCP26]:
   "Private Use", "Expert Review", "Standards Action".

6.1.  Expert Review: Evaluation Guidelines

   For registration requests where an Expert Review is required, the range 1-127 can be allocated using standards
   action [RFC2434].  Message type 0 MUST NOT
   Designated Expert SHOULD take the following general recommendations
   into consideration:

   o  The purposes of these registries are to support Standard and
      Experimental MANET routing and related protocols, and extensions
      to the same.

   o  The intention is that all registrations will be allocated because a
   zero octet signifies accompanied by a packet header.

6.2.  Packet TLV Types

   A new registry
      published RFC.

   o  In order to allow for packet TLV types must be created, with initial
   assignments as specified in Table 7.

               +---------+---------------------------------+
               |   Type  | Description                     |
               +---------+---------------------------------+
               | 128-255 | Reserved registration prior to the RFC being approved
      for private/local use. |
               +---------+---------------------------------+

                         Table 7: Packet TLV Types

   Future values in publication, the range 0-127 Designated Expert can be allocated using standards
   action [RFC2434], respecting approve the following guidelines:

   values 0-7  - MUST NOT be assigned except when a documented need
      exists
      registration once it seems clear that TLVs of an RFC is expected to be
      published.

   o  The Designated Expert will post a given type are required request to appear before all
      other TLVs in the TLV block MANET WG mailing
      list, or to a successor hereto as encoded for transmission.  Note
      that designated by the need Area Director,
      for comments and reviews.  This request will include a TLV reference
      to be processed before other TLVs does not
      however automatically translate into the Internet-Draft requesting the registration.

   o  Before a need for period of 30 days has passed, the TLV Designated Expert will
      either approve or deny the registration request and publish a note
      of the decision to appear
      before all other TLVs in the TLV block - MANET WG mailing list or its successor, as
      well as informing IANA and the order IESG.  A denial note MUST be
      justified by an explanation and, in which TLVs
      are cases where it is possible,
      suggestions as to how the request can be processed MUST modified so as to become
      acceptable SHOULD be defined, if applicable, in provided.

   For the
      protocols using this specification.

   values 8-127  - no constraints.

   If a packet TLV type is allocated then a new registry for Message Types, the following guidelines apply:

   o  Registration of a message type
   extensions implies creation of that two registries
      for message type must be created.  A specific message TLVs and message type specific
      address block TLVs.  The document which defines a
   packet TLV requests the registration
      of the message type MUST also specify the mechanism by which its indicate how these message type
   extensions specific
      TLV types are to be allocated, from among those any options in [RFC2434].

6.3.  Message TLV Types

   A new registry for message TLV types must be created, with [BCP26], and
      any initial
   assignments as allocations.  The Designated Expert SHOULD take the
      allocation policies specified for these registries into
      consideration in Table 8.

               +---------+---------------------------------+
               |   Type  | Description                     |
               +---------+---------------------------------+
               | 128-255 | Reserved reviewing the message type allocation request.

   For the registries for private/local use. |
               +---------+---------------------------------+

                        Table 8: Packet TLV Types, Message TLV Types

   Future values in and
   Address Block TLV Types, the range 0-127 can following guidelines apply:

   o  These are Hierarchical Allocations, allocation of a type creates a
      registry for the extended types corresponding to that type.  The
      document which requests the registration of the type MUST indicate
      how these extended types are to be allocated using standards
   action [RFC2434], respecting allocated, from any options in
      [BCP26], and any initial allocations.  Normally this allocation
      should also be Expert Review, but with the following guidelines: possible allocation of
      some type extensions as Reserved, Experimental and/or Private.

   o  TLV type values 0-7  - MUST NOT be assigned registered except when a
      documented need exists that TLVs of a given type are required to
      appear before all other TLVs in the TLV block as encoded for
      transmission.  Note that the need for a TLV to be processed before
      other TLVs does not however automatically translate into a need
      for the TLV to appear before all other TLVs in the TLV block - the (the
      order in which TLVs are to be processed MUST be defined, if
      applicable, in the protocols using this specification.

   values 8-127  - no constraints.

   If a message TLV type is allocated then a new registry specification).

   o  The request for type
   extensions of that type must be created.  A document which defines a
   message TLV type MUST also specify include the mechanism by which its type
   extensions are allocated, from among those in [RFC2434].

6.4. specification of the
      permitted size, syntax of any internal structure of, and meaning
      of, the value field (if any) of the TLV.

   For the registries for Message TLV Types and Address Block TLV Types

   A new registry for address block Types,
   the following additional guidelines apply:

   o  TLV types must type values 0-127 are common for all message types.  TLVs
      which receive registrations from the 0-127 interval SHOULD be created, with
   initial assignments as specified
      modular in Table 9.

               +---------+---------------------------------+
               |   Type  | Description                     |
               +---------+---------------------------------+
               | 128-255 | Reserved for private/local use. |
               +---------+---------------------------------+

                     Table 9: Address Block design to allow reuse among protocols.

   o  TLV Types

   Future type values 128-223 are message type specific TLV type values,
      relevant only in the range 0-127 can be allocated using standards
   action [RFC2434], respecting context of the following guidelines: containing message type.
      Registration of TLV type values 0-7  - MUST NOT be assigned except when within the 128-223 interval
      require that a documented need registry in the 128-223 interval exists that TLVs of for a given
      specific message type value (see Section 6.2.1), and registrations
      are required to appear before all
      other TLVs made in accordance with the allocation policies specified for
      these message type specific registries.  Message type specific TLV block as encoded
      types SHOULD be registered for transmission.  Note
      that TLVs which the need Designated Expert
      deems too message type specific for registration of a 0-127 value.
      Multiple different TLV to definitions MAY be processed before other TLVs does not
      however automatically translate into a need for assigned the same TLV appearing
      before all other TLVs in
      type value within the 128-223 interval, given that they are
      associated with different message type specific TLV block - the order type
      registries.  Where possible, existing global TLV definitions and
      modular global TLV definitions for registration in which TLVs
      are to the 0-127 range
      SHOULD be processed MUST used.

6.2.  Message Types

   A new registry for message types must be defined, if applicable, created, with initial
   assignments and allocation policies as specified in the
      protocols using this specification.

   values 8-127  - no constraints.

   If an address block Table 6.

               +---------+-------------+-------------------+
               |   Type  | Description | Allocation Policy |
               +---------+-------------+-------------------+
               |  0-223  | Unassigned  | Expert Review     |
               | 224-255 | Unassigned  | Experimental Use  |
               +---------+-------------+-------------------+

                          Table 6: Message Types

6.2.1.  Message Type Specific TLV Registry Creation

   When a message type is allocated registered then a new registry registries MUST be specified
   for both message type specific message TLVs (Table 8) and message
   type specific address block TLVs (Table 10).  A document which
   creates a message type specific TLV registry MUST also specify the
   mechanism by which message specific TLV types are allocated, from
   among those in [BCP26].

6.3.  Packet TLV Types

   A new registry for packet TLV types must be created, with initial
   assignments and allocation policies as specified in Table 7.

               +---------+-------------+-------------------+
               |   Type  | Description | Allocation Policy |
               +---------+-------------+-------------------+
               |  0-223  | Unassigned  | Expert Review     |
               | 224-255 | Unassigned  | Experimental Use  |
               +---------+-------------+-------------------+

                         Table 7: Packet TLV Types

6.3.1.  Packet TLV Type Extension Registry Creation

   When a packet TLV type is registered then a new registry for type
   extensions of that type extensions of that type must be created.  A document which defines an address block a
   packet TLV type MUST also specify the mechanism by which its type
   extensions are allocated, from among those in
   [RFC2434].

7.  Security Considerations

   This specification does not describe a protocol; it describes a
   packet format.  As such it does not specify any security
   considerations, these are matters [BCP26].

6.4.  Message TLV Types

   A new registry for a protocol using this
   specification.  However two mechanisms which are enabled by this
   specification, message type independent message TLV types must be
   created, with initial assignments and may form part of a security approach allocation policies as
   specified in a protocol
   using this specification, Table 8.

        +---------+-----------------------+-----------------------+
        |   Type  | Description           | Allocation Policy     |
        +---------+-----------------------+-----------------------+
        |  0-127  | Unassigned            | Expert Review         |
        | 128-223 | Message Type Specific | Reserved, see Table 9 |
        | 224-255 | Unassigned            | Experimental Use      |
        +---------+-----------------------+-----------------------+

                        Table 8: Message TLV Types

   Message TLV Types 128-223 are described in Section 8.1.  There is
   however no requirement that reserved for message type specific
   Message TLVs, for which a protocol using this specification
   should use either.

7.1.  Authentication Suggestions

   The authentication suggestions made here, are based on new registry is created with the intended
   usage in Appendix A, specifically that:

   o  Messages are designed to be carriers of protocol information and
      MAY, at each hop, be forwarded and/or processed by the protocol
      using this specification.

   o  Packets are designed to carry a number
   registration of messages between
      neighboring nodes in a single transmission message type, and over a single
      logical hop.

   Consequently:

   o  For forwarded messages where the with initial assignments and
   allocation policies as specified in Table 9.

       +---------+-----------------------------+-------------------+
       |   Type  | Description                 | Allocation Policy |
       +---------+-----------------------------+-------------------+
       |  0-127  | Common to all Message Types | Reserved          |
       | 128-223 | Message Type Specific       | See Below         |
       | 224-255 | Common to all Message Types | Reserved          |
       +---------+-----------------------------+-------------------+

                Table 9: Message Specific Message TLV Types

   Allocation policies for message is unchanged by
      forwarding nodes, then end-to-end security MAY type specific message TLV types MUST
   be implemented,
      between nodes specified when creating the registry associated with an existing security association, by including the
   containing message type, see Section 6.2.1.

6.4.1.  Message TLV Type Extension Registry Creation

   If a suitable message TLV containing type is registered then a cryptographic signature in the
      message.  Since <hop-count> and <hop-limit> are the only fields new registry for type
   extensions of that should type must be modified when such created.  A document which defines a
   message is forwarded in this
      manner, this signature can be calculated based on the entire
      message, including TLV type MUST also specify the mechanism by which its type
   extensions are allocated, from among those in [BCP26].

6.5.  Address Block TLV Types

   A new registry for message header, with the <hop-count> and
      <hop-limit> fields set to 0 if present.

   o  Hop-by-hop packet level security MAY type independent address block TLV types
   must be implemented, between nodes created, with an existing security association, by including a suitable
      packet TLV containing a cryptographic signature to the packet.
      Since packets are received as transmitted, this signature can be
      calculated based on the entire packet, or on parts thereof initial assignments and allocation policies as
      appropriate.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use
   specified in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines Table 10.

       +---------+-----------------------+------------------------+
       |   Type  | Description           | Allocation Policy      |
       +---------+-----------------------+------------------------+
       |  0-127  | Unassigned            | Expert Review          |
       | 128-223 | Message Type Specific | Reserved, see Table 11 |
       | 224-255 | Unassigned            | Experimental Use       |
       +---------+-----------------------+------------------------+

                     Table 10: Address Block TLV Types

   Address Block TLV Types 128-223 are reserved for Writing an
              IANA Considerations Section in RFCs", RFC 2434, BCP 26,
              October 1998.

8.2.  Informative References

   [RFC3626]  Clausen, T. and P. Jacquet, "The Optimized Link State
              Routing Protocol", RFC 3626, October 2003.

Appendix A.  Intended Usage

   The packet and message format specified in this document type
   specific Address Block TLVs, for which a new registry is designed
   to carry MANET routing protocol messages created with
   the registration of a message type, and signals between MANET
   routers, with initial assignments and to support scope limited diffusion (flooding) as well
   allocation policies as
   point-to-point delivery.

   Specifically:

   o  Packets are transmitted over a single logical hop and are not
      forwarded.  Messages are designed specified in Table 11.

       +---------+-----------------------------+-------------------+
       |   Type  | Description                 | Allocation Policy |
       +---------+-----------------------------+-------------------+
       |  0-127  | Common to be able all Message Types | Reserved          |
       | 128-223 | Message Type Specific       | See Below         |
       | 224-255 | Common to all Message Types | Reserved          |
       +---------+-----------------------------+-------------------+

            Table 11: Message Specific Address Block TLV Types

   Allocation policies for message type specific address block TLV types
   MUST be forwarded over
      one or more logical hops, in specified when creating the registry associated with the
   containing message type, see Section 6.2.1.

6.5.1.  Address Block TLV Type Extension Registry Creation

   When an address block TLV type is registered then a new packet registry for each logical hop.
      Each logical hop may consist of one or more IP hops.  Packets may
      contain a different combination
   type extensions of messages for each logical hop.
      Packets may that type must be formed from messages from more than one MANET
      routing protocol; the use of created.  A document which
   defines a single message TLV type space for all MUST also specify the mechanism by which
   its type extensions are allocated, from among those in [BCP26].

7.  Security Considerations

   This specification does not describe a protocol; it describes a
   packet format.  As such protocols allows it does not specify any security
   considerations, these messages to be separated by protocol.

   o  Scope limited flooding is supported are matters for messages thus:

      *  If the mhasorig a protocol using this
   specification.  However some security mechanisms are enabled by this
   specification, and mhasseqnum may form part of a protocol using this
   specification.  Mechanisms which may form part of an authentication
   and bits integrity approach in the <msg-semantics>
         field are both set ('1') then the message header provides for
         duplicate suppression, a protocol using the identifier consisting this specification, are
   described in Section 7.1.  Mechanisms which may form part of the
         message's <msg-orig-addr>, <msg-seq-num>, and, if the
         mistypedep bit a
   confidentiality approach in the <msg-semantics> field is set ('1), <msg-
         type>.  These serve to uniquely identify the message a protocol using this specification, are
   described in the
         network within the time period until <msg-seq-num> Section 7.2.  There is repeated,
         i.e. wraps around to a matching value if used sequentially.

      *  If however no requirement that a
   protocol using this specification should use either.

7.1.  Authentication and Integrity Suggestions

   The authentication and integrity suggestions made here, are based on
   the mhashoplimit bit intended usage in the <msg-semantics> field is set
         ('1'), then the message header provides the information Appendix A, specifically that:

   o  Messages are designed to make
         forwarding decisions for scope limited diffusion (flooding).
         This may be carriers of protocol information and
      MAY, at each hop, be forwarded and/or processed by any appropriate flooding mechanism specified by
         a the protocol
      using this specification.

      *  <msg-hop-limit> SHOULD, if present, be decremented, usually by
         one, if

   o  Packets are designed to carry a number of messages between
      neighboring nodes in a single transmission and over a single
      logical hop.

   Consequently:

   o  For forwarded messages where the message is forwarded.

      *  <msg-hop-count> SHOULD, if present, be incremented, usually unchanged by
         one, if the message is forwarded.

Appendix B.  Compatibility Requirements for Future Versions

   This specification defines packets
      forwarding nodes, then end-to-end authentication and messages integrity MAY
      be implemented, between nodes with version zero
   (0).

   Although this specification does not define packet and an existing security
      association, by including a suitable message
   versions greater than zero, any future version of this specification
   MUST, for backwards compatibility, satisfy the following:

   o  If the packet version is greater than zero, then TLV containing a <pkt-header>
      element MUST be included
      cryptographic signature in the packet, which MUST include a <pkt-
      version> element indicating the packet version.

   o  If message.  Since <hop-count> and
      <hop-limit> are the only fields that should be modified when such
      a message version is greater than zero, then a <msg-version>
      element MUST be included forwarded in this manner, this signature can be
      calculated based on the <msg-header>, indicating entire message, including the message version.

   o  The initial octets of a <pkt-header>, up
      header, with the <hop-count> and <hop-limit> fields set to 0 if
      present.

   o  Hop-by-hop packet level authentication and integrity MAY be
      implemented, between nodes with an existing security association,
      by including <pkt-
      version>, MUST a suitable packet TLV containing a cryptographic
      signature to the packet.  Since packets are received as
      transmitted, this signature can be preserved calculated based on the entire
      packet, or on parts thereof as in appropriate.

7.2.  Confidentiality Suggestions

   This specification does not explicitly enable protecting packet/
   message confidentiality.  Such confidentiality would normally, when
   required, be provided hop-by-hop either by link-layer mechanisms, or
   at the IP layer using [RFC4301], and would apply to a packet only.

   It is possible, however, for a protocol using this specification, specification to
   protect the confidentiality of information included in order a packet,
   message or address block TLV by specifying that packets the value field of versions greater than zero
   that TLV type be encrypted, as well as specifying the encryption
   mechanism.

   In an extreme case, all information can be correctly
      recognized (and discarded) encrypted by implementations of this version of
      this specification. defining
   either:

   o  The initial octets  A packet, consisting of only a <msg-header>, up until packet header (with no messages),
      and including <msg-
      length>, MUST be preserved as in this specification, in order containing a packet TLV, where the packet TLV type indicates
      that its value field contains one or more encrypted messages.
      Upon receipt, and once this packet TLV is successfully decrypted,
      these messages of versions greater than zero can may then be correctly recognized
      (and discarded) by implementations of parsed according to this version of specification
      and processed according to the protocol using this specification.

Appendix C.  Examples

   This appendix contains some examples

   o  A message, consisting of parts only a message header and a single
      message TLV, where the message TLV type indicates that its value
      field contains an encrypted version of the message's remaining
      message TLVs, address blocks and address block TLVs.  Upon
      receipt, and once this specification.

C.1.  Address Block Examples

   The following examples illustrate how some combinations of addresses message TLV is successfully decrypted, the
      complete message may then be efficiently included in address blocks.  These examples are
   for IPv4, with address-length equal parsed according to 4. a, b, c etc. represent
   distinct, non-zero, octet values.

   Note that it is permissible this
      specification and processed according to use a less efficient representation,
   in particular one in which the ahashead and ahasfulltail bits of protocol using this
      specification.

   In either case, the
   semantics octet are cleared ('0'), and hence head-length = 0, tail-
   length = 0, mid-length = address-length, and (with no address
   prefixes) protocol MUST define the address block consists of encrypted TLV type, as
   well as the number format of addresses, the
   semantics octet with encrypted data block contained in the value 0, and a list
   field of the uncompressed
   addresses.  This is also the most efficient way TLV.

8.  References

8.1.  Normative References

   [RFC2119]     Bradner, S., "Key words for use in RFCs to represent a single
   address, Indicate
                 Requirement Levels", RFC 2119, BCP 14, March 1997.

   [BCP26]       Narten, T. and the only way to represent, H. Alvestrand, "Guidelines for example, a.b.c.d and
   e.f.g.h Writing
                 an IANA Considerations Section in one address block.

   Examples:

   o  To include a.b.c.d, a.b.e.f RFCs", RFC 5226,
                 BCP 26, May 2008.

   [RFC4291]     Hinden, R. and a.b.g.h:

      *  head-length = 2;

      *  tail-length = 0;

      *  mid-length = 2;

      *  <addr-semantics> has ahashead set (value 1);

      *  <tail-length> S. Deering, "IP Version 6 Addressing
                 Architecture", RFC 4291, February 2006.

   [SingleUNIX]  IEEE Std 1003.1, The Open Group, and ISO/IEC JTC
                 1/SC22/WG15, "Single UNIX Specification, Version 3,
                 2004 Edition", April 2004.

   [POSIX]       ISO/IEC Standard 9945-1:2003, "Portable Operating
                 System Interface (POSIX) - Part 1: Base Definitions",
                 January 2003.

   [ECMAScript]  ISO/IEC Standard 9845-1:2003, "Ecma-262, ECMAScript
                 Language Specification", January 2003.

8.2.  Informative References

   [RFC3626]     Clausen, T. and <tail> are omitted.

      The address block is then 3 1 2 a b c d e f g h (11 octets).

   o  To include a.b.c.g and d.e.f.g:

      *  head-length = 0;

      *  tail-length = 1;

      *  mid-length = 3;

      *  <addr-semantics> has ahasfulltail set (value 2);
      *  <head-length> P. Jacquet, "The Optimized Link State
                 Routing Protocol", RFC 3626, October 2003.

   [RFC4301]     Kent, S. and <head> are omitted.

      The address block is then 2 2 K. Seo, "Security Architecture for the
                 Internet Protocol", RFC 4301, December 2005.

   [Stevens]     Stevens, W., "TCP/IP Illustrated  Volume 1 g a b c d e f (10 octets).

   o  To include a.b.d.e and a.c.d.e:

      *  head-length = 1;

      *  tail-length = 2;

      *  mid-length = 1;

      *  <addr-semantics> has ahashead and ahasfulltail set (value 3). - The address block is then 2 3 1 a 2 d e b c (9 octets).

   o  To include a.b.0.0, a.c.0.0, and a.d.0.0:

      *  head-length = 1;

      *  tail-length = 2;

      *  mid-length = 1;

      *  <addr-semantics> has ahashead and ahaszerotail set (value 5);

      *  <tail> is omitted.
                 Protocols.", 1994.

Appendix A.  Intended Usage

   The address block is then 3 5 1 a 2 b c d (8 octets).

   o  To include a.b.0.0 packet and c.d.0.0:

      *  head-length = 0;

      *  tail-length = 2;

      *  mid-length = 2;

      *  <addr-semantics> has ahaszerotail set (value 4);

      *  <head> message format specified in this document is designed
   to carry MANET routing protocol signaling between MANET routers, and <tail>
   to support scope limited diffusion (flooding) as well as point-to-
   point delivery.

   Specifically:

   o  Packets are omitted.

      The address block is then 2 4 2 transmitted over a b c d (7 octets).

   o  To include a.b.0.0/n and c.d.0.0/n:

      *  head-length = 0;
      *  tail-length = 2;

      *  mid-length = 2;

      *  <addr-semantics> has ahaszerotail single logical hop and ahassingleprelen set
         (value 12);

      *  <head> and <tail> are omitted.

      The address block is then 2 12 2 not
      forwarded.  Messages are designed to be able to be forwarded over
      one or more logical hops, in a b c d n (8 octets). new packet for each logical hop.
      Each logical hop may consist of one or more IP hops.  Packets may
      contain a different combination of messages for each logical hop.
      Packets may be formed from messages from more than one MANET
      routing protocol; the use of a single message type space for all
      such protocols allows these messages to be separated by protocol.

   o  To include a.b.0.0/n and c.d.0.0/m:

      *  head-length = 0;

      *  tail-length = 2;

      *  mid-length = 2;

      *  <addr-semantics> has ahaszerotail and ahasmultiprelen set
         (value 20);  Scope limited flooding is supported for messages thus:

      *  <head>  If the mhasorig and <tail> mhasseqnum msg-flags are omitted.

      The address block is both set ('1')
         then 2 20 2 a b c d n m (9 octets).

C.2.  TLV Examples

   Assuming the definition message header provides for duplicate suppression,
         using the identifier consisting of an address block TLV with type EXAMPLE1
   (and no type extension) which has single octet values per address,
   then the message's <msg-orig-
         addr>, <msg-seq-num>, and, if values a, a, b and c are the mistypedep flag in the <msg-
         flags> field is set ('1'), <msg-type>.  These serve to be associated with uniquely
         identify the four
   addresses message in the preceding address block, where c network within the time period
         until <msg-seq-num> is repeated, i.e. wraps around to a default
         matching value
   that can be omitted, if used sequentially.

      *  If the mhashoplimit msg-flag is set ('1'), then this can the message
         header provides the information to make forwarding decisions
         for scope limited diffusion (flooding).  This may be done in by any
         appropriate flooding mechanism specified by a number of ways.

   Examples:

   o  Using one multivalue TLV covering all of the addresses: protocol using
         this specification.

      *  <tlv-semantics> has thasvalue and tismultivalue set (value 36);  <msg-hop-limit> SHOULD, if present, be decremented, usually by
         one, if the message is forwarded.

      *  <index-start>  <msg-hop-count> SHOULD, if present, be incremented, usually by
         one, if the message is forwarded.

Appendix B.  Multiplexing and <index-stop> are omitted;

      *  <length> = 4 (single-length = 1).

      * Demultiplexing

   The TLV packet and message format specified in this document is then EXAMPLE1 36 4 designed
   to allow zero or more messages to be contained within a single packet
   (e.g. a b c (7 octets).

   o  Using one multivalue TLV omitting single IP datagram or UDP datagram).  Such messages may be
   from the last address:

      *  <tlv-semantics> has thasvalue, thasmultiindex same or may be from different protocols.  In the latter
   case, multiplexing of outgoing messages from different protocols and tismultivalue
         set (value 52);

      *  <index-start> = 0;

      *  <index-stop> = 2

      *  <length> = 3 (single-length = 1).

      *  The TLV is then EXAMPLE1 52 0 2 3
   demultiplexing of incoming messages contained within a single packet,
   must be addressed.

   Multiplexing messages of different message types from different
   protocols running on a given node into a b (8 octets).

   o  Using two single value TLVs, omitting packet, rather than
   to have each protocol generate its own packet, is an optimization.
   Doing so may reduce the last address.  First:

      *  <tlv-semantics> has thasvalue and thasmultiindex set (value
         20);

      *  <index-start> = 0;

      *  <index-stop> = 1;

      *  <length> = 1;

      *  <value> = a.

      *  The TLV is then EXAMPLE1 20 0 1 1 a (6 octets).

      Second:

      *  <tlv-semantics> has thasvalue and thassingleindex set (value
         12);

      *  <index-start> = 2;

      *  <index-stop> is omitted;

      *  <length> = 1;

      *  <value> = b.

      *  The TLV is then EXAMPLE1 12 2 1 b (5 octets).

      Total length total number of octets as transmitted by that
   node, while not doing so should not have any adverse effects on
   protocol functioning.

   Having two different protocols (or, two different instances of TLVs is 11 octets.

   In this case the first
   same protocol) generate messages of these is the most efficient.  In other
   cases patterns such as same message type on the others may be preferred.  Regardless same
   interface may, however, cause inconsistencies, unless this message
   generation is coordinated.

   If a packet contains messages destined for multiple protocols,
   correct functioning of
   efficiency, any each of these may be used.

   Assuming protocols depends on the definition of an address block TLV with type EXAMPLE2
   (and no type extension) which has no value, which is
   appropriate messages being delivered to be associated
   with each protocol.

   If multiple protocols which are using the second packet and third addresses message format
   specified in an address block, then this
   can be indicated with a single TLV:

   o  <tlv-semantics> has thasmultiindex set (value 16);

   o  <index-start> = 1;

   o  <index-stop> = 2;

   o  <length> and <value> document are omitted.

   o  The TLV is then EXAMPLE2 16 1 2 (4 octets).

   Assuming running over the definition same UDP port or IP
   protocol number, multiplexing and demultiplexing of messages SHOULD
   be accomplished based on message types, ensuring a correspondence
   between message TLV with type EXAMPLE3 (and no
   type extension) which can take types and protocol instances thus:

   o  For each message type, a value field of any length, protocol - unless specified otherwise,
      the one making the IANA reservation for such
   a TLV with 8 octets that message type - SHOULD
      be designated as the "owner" of data (a to h):

   o  <tlv-semantics> has thasvalue set (value 4); that message type.

   o  <index-start>  On a given interface, and <index-stop> are omitted;

   o  <length> = 8.

   o  The TLV is then EXAMPLE3 4 8 for a b c d e f g h (11 octets).

   If, in this example, the number of data octets were 256 given UDP port or greater
   then <tlv-semantics> would also have thasextlen set and have value 6.
   The length would require two octets (most significant first).  The
   TLV length would be 4 + N octets, where N is the number IP protocol
      number, only one protocol instance of data
   octets (it can be 3 + N octets if N a protocol which is 255 or less).

Appendix D.  Illustrations

   This informative appendix illustrates the elements, which are
   normatively specified in Section 5 using regular expressions.
   Examples with version fields are omitted, as not needed when using
   this version
      designated "owner" of this specification (although permitted).

   Bits labeled Rsv or R must a message type SHOULD be cleared ('0').  Bits labeled C, N, or M
   may running,

   o  Any incoming messages of a given message type SHOULD be cleared ('0') or set ('1').

D.1.  Packet

   Possible options for delivered
      to the <packet> element.  These are differentiated
   by their second (semantics) octet, except protocol instance on the last, receiving interface which starts with
   a non-zero octet.  The packet may include any number (zero or more) "owns"
      messages of messages, except in the last case, when there must that type.  Specifically, any incoming message SHOULD
      NOT be one or delivered to any other protocol instances and SHOULD NOT be
      delivered to more
   messages.  The number of than one protocol instance.

   o  Any outgoing messages is determined from the size of a given type SHOULD be generated and
      transmitted only by the
   packet (either the <pkt-size> field if present, or from the network protocol instance which "owns" that
      message type.

   o  If two protocols both wish to use the same message type (e.g.
      through inspecting information carried in messages of that type,
      or transport through inserting information into generated messages of that
      type) then this interaction SHOULD be specified by the protocol employed).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Rsv |C|0|0|0|0|                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2
      which is the designated "owner" of that message type.

Appendix C.  Examples

   This appendix contains some examples of parts of this specification.

C.1.  Address Block Examples

   The following examples illustrate how some combinations of addresses
   may be efficiently included in address blocks.  These examples are
   for IPv4, with address-length equal to 4. a, b, c etc. represent
   distinct, non-zero, octet values.

   Note that it is permissible to use a less efficient representation,
   in particular one in which the ahashead and ahasfulltail flags are
   cleared ('0'), and hence head-length = 0, tail-length = 0, mid-length
   = address-length, and (with no address prefixes) the address block
   consists of the number of addresses, <addr-flags> with value 0, and a
   list of the unaggregated addresses.  This is the most efficient way
   to represent a single address, and the only way to represent, for
   example, a.b.c.d and e.f.g.h in one address block.

   Examples:

   o  To include a.b.c.d, a.b.e.f and a.b.g.h:

      *  head-length = 2;

      *  tail-length = 0;

      *  mid-length = 2;

      *  <addr-flags> has ahashead set (value 128);

      *  <tail-length> and <tail> are omitted.

      The address block is then 3 4 5 6 7 8 9 0 1 128 2 3 4 5 6 7 8 9 0 1 a b c d e f g h (11 octets).

   o  To include a.b.c.g and d.e.f.g:

      *  head-length = 0;

      *  tail-length = 1;

      *  mid-length = 3;

      *  <addr-flags> has ahasfulltail set (value 64);

      *  <head-length> and <head> are omitted.

      The address block is then 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Rsv |C|0|0|1|0|          Packet Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Message                            |
     |                                                               |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0 64 1 g a b c d e f (10 octets).

   o  To include a.b.d.e and a.c.d.e:

      *  head-length = 1;

      *  tail-length = 2;

      *  mid-length = 1;

      *  <addr-flags> has ahashead and ahasfulltail set (value 192).

      The address block is then 2                   3
      0 192 1 a 2 d e b c (9 octets).

   o  To include a.b.0.0, a.c.0.0, and a.d.0.0:

      *  head-length = 1;

      *  tail-length = 2;

      *  mid-length = 1;

      *  <addr-flags> has ahashead and ahaszerotail set (value 160);

      *  <tail> is omitted.

      The address block is then 3 4 5 6 7 8 9 0 160 1 a 2 3 4 5 6 7 8 9 0 1 b c d (8 octets).

   o  To include a.b.0.0 and c.d.0.0:

      *  head-length = 0;

      *  tail-length = 2;

      *  mid-length = 2;

      *  <addr-flags> has ahaszerotail set (value 32);
      *  <head> and <tail> are omitted.

      The address block is then 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Rsv |C|0|1|0|0|    Packet Sequence Number     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Message                            |
     |                                                               |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1 32 2                   3
      0 1 a b c d (7 octets).

   o  To include a.b.0.0/n and c.d.0.0/n:

      *  head-length = 0;

      *  tail-length = 2;

      *  mid-length = 2;

      *  <addr-flags> has ahaszerotail and ahassingleprelen set (value
         48);

      *  <head> and <tail> are omitted.

      The address block is then 2 48 2 a b c d n (8 octets).

   o  To include a.b.0.0/n and c.d.0.0/m:

      *  head-length = 0;

      *  tail-length = 2;

      *  mid-length = 2;

      *  <addr-flags> has ahaszerotail and ahasmultiprelen set (value
         40);

      *  <head> and <tail> are omitted.

      The address block is then 2 40 2 3 a b c d n m (9 octets).

C.2.  TLV Examples

   Assuming the definition of an address block TLV with type EXAMPLE1
   (and no type extension) which has single octet values per address,
   then if values a, a, b and c are to be associated with the four
   addresses in the preceding address block, where c is a default value
   that can be omitted, then this can be done in a number of ways.

   Examples:

   o  Using one multivalue TLV covering all of the addresses:

      *  <tlv-flags> has thasvalue and tismultivalue set (value 20);
      *  <index-start> and <index-stop> are omitted;

      *  <length> = 4 5 6 7 8 9 0 1 (single-length = 1).

      *  The TLV is then EXAMPLE1 20 4 a a b c (7 octets).

   o  Using one multivalue TLV omitting the last address:

      *  <tlv-flags> has thasmultiindex, thasvalue and tismultivalue set
         (value 52);

      *  <index-start> = 0;

      *  <index-stop> = 2

      *  <length> = 3 4 5 6 7 8 9 (single-length = 1).

      *  The TLV is then EXAMPLE1 52 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Rsv |C|0|1|1|0|          Packet Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Packet Sequence Number     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a a b (8 octets).

   o  Using two single value TLVs, omitting the last address.  First:

      *  <tlv-flags> has thasmultiindex and thasvalue set (value 48);

      *  <index-start> = 0;

      *  <index-stop> = 1;

      *  <length> = 1;

      *  <value> = a.

      *  The TLV is then EXAMPLE1 48 0 1                   2                   3
      0 1 a (6 octets).

      Second:

      *  <tlv-flags> has thassingleindex and thasvalue set (value 80);

      *  <index-start> = 2;

      *  <index-stop> is omitted;

      *  <length> = 1;

      *  <value> = b.

      *  The TLV is then EXAMPLE1 80 2 3 4 5 6 7 8 9 0 1 b (5 octets).

      Total length of TLVs is 11 octets.

   In this case the first of these is the most efficient.  In other
   cases patterns such as the others may be preferred.  Regardless of
   efficiency, any of these may be used.

   Assuming the definition of an address block TLV with type EXAMPLE2
   (and no type extension) which has no value, which is to be associated
   with the second and third addresses in an address block, then this
   can be indicated with a single TLV:

   o  <tlv-flags> has thasmultiindex set (value 32);

   o  <index-start> = 1;

   o  <index-stop> = 2;

   o  <length> and <value> are omitted.

   o  The TLV is then EXAMPLE2 32 1 2 3 (4 octets).

   Assuming the definition of a message TLV with type EXAMPLE3 (and no
   type extension) which can take a value field of any length, for such
   a TLV with 8 octets of data (a to h):

   o  <tlv-flags> has thasvalue set (value 16);

   o  <index-start> and <index-stop> are omitted;

   o  <length> = 8.

   o  The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets).

   If, in this example, the number of data octets were 256 or greater
   then <tlv-flags> would also have thasextlen set and have value 24.
   The length would require two octets (most significant first).  The
   TLV length would be 4 5 6 7 8 9 0 1 2 + N octets, where N is the number of data
   octets (it can be 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| + N octets if N is 255 or less).

Appendix D.  Illustrations

   This informative appendix illustrates the elements which are
   normatively specified in Section 5.

   Bits labeled Rsv |C|1|0|0|0|                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     | or R should be cleared ('0').  Bits labeled C, N, or
   M may be cleared ('0') or set ('1').

D.1.  Packet TLV Block                        |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                            Message                            |
     |                                                               |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Possible options for the <packet> element.  These are differentiated
   by the flags field in the first octet.  The packet may include any
   number (zero or more) of Messages.  The number of Messages is
   determined from when the packet is exhausted, given the packet length
   from the network layer.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Rsv |C|1|0|1|0|          Packet Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Packet TLV Block                        |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |0|0|0|0|0|0|C|R|                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                            Message                            |
     |                                                               |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Rsv |C|1|1|0|0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0|0|0|1|0|C|R|    Packet Sequence Number     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Packet TLV Block                        |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                            Message                            |
     |                                                               |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Rsv |C|1|1|1|0|          Packet Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Packet Sequence Number
     |0|0|0|0|0|1|C|R|                                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                       Packet TLV Block                        |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                            Message                            |
     |                                                               |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|0|0|0|1|1|C|R|    Packet Sequence Number     |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                       Packet TLV Block                        |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                                               |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                            Message                            |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D.2.  Message

   Possible options for the <message> element.  These are differentiated
   by their second (semantics) (flags) octet.  The length of the message body Message Body is
   determined using the <msg-size> Message Size field, which includes is the combined length
   of all the fields shown.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|0|0|0|0|0|  |0|0|0|0|0|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|0|0|0|1|0|  |1|0|0|0|0|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|0|0|1|0|0|  |0|1|0|0|0|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|0|0|1|1|0|  |1|1|0|0|0|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|0|1|0|0|0|  |0|0|1|0|0|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Count   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|0|1|0|1|0|  |1|0|1|0|0|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Count   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|0|1|1|0|0|  |0|1|1|0|0|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |   Hop Count   |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|0|1|1|1|0|  |1|1|1|0|0|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |   Hop Count   |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|1|0|0|0|0|  |0|0|0|1|N|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Message Sequence Number    |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|1|0|0|1|0|  |1|0|0|1|N|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Message Sequence Number    |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|1|0|1|0|0|  |0|1|0|1|N|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |    Message Sequence Number    |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|1|0|1|1|0|  |1|1|0|1|N|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |    Message Sequence Number    |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|0|1|1|0|0|0|  |0|0|1|1|N|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Count   |    Message Sequence Number    |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|1|1|0|1|0|  |1|0|1|1|N|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Count   |    Message Sequence Number    |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|0|1|1|1|0|0|  |0|1|1|1|N|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |   Hop Count   |    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |R|C|N|1|1|1|1|0|  |1|1|1|1|N|C|Rsv|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |   Hop Count   |    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D.3.  Message Body

   Format of a message body (the <message> element excluding its initial
   <msg-header> element).  The message body includes one Message TLV
   Block (containing zero or more TLVs) and may include any number (zero
   or more) of address block Address Block and address Address TLV block Block pairs.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message TLV Block                       |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                         Address Block                         |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                       Address TLV Block                       |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                         Address Block                         |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                       Address TLV Block                       |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D.4.  Address Block

   Possible options for the <addr-block> element.  These are
   differentiated by their second (semantics) (flags) octet.  The number of
   <mid> Mid
   elements is equal to the number of addresses (except when mid-
   length mid-length
   is zero, when there are no <mid> Mid elements).  Where a variable number of <prefix-length>
   Prefix Length fields is shown, their number is equal to the number of
   addresses.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  | Rsv  |0|0|0|0|0| Rsv |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Mid (cont)           |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Mid (cont)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |1|0|0|0|0| Rsv |0|0|0|0|1| |  Head Length  |     Head      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |              Mid              |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |0|1|0|0|0| Rsv |0|0|0|1|0| |  Tail Length  |     Tail      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Tail (cont)  |              Mid              |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |1|1|0|0|0| Rsv |0|0|0|1|1| |  Head Length  |     Head      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |  Tail Length  |             Tail              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  | Rsv  |0|0|1|0|0| Rsv |  Tail Length  |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Mid (cont)   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |1|0|1|0|0| Rsv |0|0|1|0|1| |  Head Length  |     Head      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |  Tail Length  |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |0|0|0|1|0| Rsv |0|1|0|0|0| |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Mid (cont)           |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Mid (cont)           | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |1|0|0|1|0| Rsv |0|1|0|0|1| |  Head Length  |     Head      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |              Mid              |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              Mid              | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |0|1|0|1|0| Rsv |0|1|0|1|1|  Head Length  |     Head      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont) |  Tail Length  |     Tail      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Tail (cont)  |              Mid              |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Length |
     +-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |1|1|0|1|0| Rsv |0|1|0|1|0|  Tail |  Head Length  |     Tail     Head      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Tail  Head (cont)  |  Tail Length  |             Tail              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |0|0|1|1|0| Rsv |0|1|1|0|0| |  Tail Length  |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Mid (cont)   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              Mid              | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |1|0|1|1|0| Rsv |0|1|1|0|1| |  Head Length  |     Head      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |  Tail Length  |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |0|0|0|0|1| Rsv |1|0|0|0|0| |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Mid (cont)           |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Mid (cont)           | Prefix Length |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  | Rsv  |1|0|0|0|1| Rsv |  Head Length  |     Head      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |              Mid              |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              Mid              | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |0|1|0|0|1| Rsv |1|0|0|1|0| |  Tail Length  |     Tail      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Tail (cont)  |              Mid              |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              Mid              | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |1|1|0|0|1| Rsv |1|0|0|1|1| |  Head Length  |     Head      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |  Tail Length  |             Tail              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Length |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     :                              ...                              :
     |                                               +-+-+-+-+-+-+-+-+
     |                                               | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |  |0|0|1|0|1| Rsv |1|0|1|0|0| |  Tail Length  |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Mid (cont)   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              Mid              | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  | Rsv  |1|0|1|0|1| Rsv |  Head Length  |     Head      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |  Tail Length  |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              | Prefix Length |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D.5.  TLV Block

   Format if of a <tlv-block> element.  There may be any number (zero or
   more) of TLVs, with total length of the TLVs (in octets) equal to the length
   Length field.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Length             |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                              TLV                              |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                              TLV                              |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D.6.  TLV

   Possible options for the <tlv> element.  These are differentiated by
   their second (semantics) (flags) octet.  If there are no index fields then this
   may be a packet, message or address block TLV, if there is are one or
   two index fields then this must be an address block TLV.  The
   length Length
   field gives the length of the value field (in octets).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|0|0|0|0|0|0|      |0|0|0|0|0|0|Rsv|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|0|0|0|0|0|1|      |1|0|0|0|0|0|Rsv|   Type Ext    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|0|0|0|0|1|0|      |0|1|0|0|0|0|Rsv|  Index Start  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|0|0|0|0|1|1|      |1|1|0|0|0|0|Rsv|   Type Ext    |  Index Start  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|0|0|0|1|0|0|      |0|0|1|0|0|0|Rsv|  Index Start  |  Index Stop   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|0|0|0|1|0|1|      |1|0|1|0|0|0|Rsv|   Type Ext    |  Index Start  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Index Stop   |
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|M|0|1|0|0|0|      |0|0|0|1|0|M|Rsv|    Length     |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|M|0|1|0|0|1|      |1|0|0|1|0|M|Rsv|   Type Ext    |    Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|0|0|1|0|1|0|      |0|1|0|1|0|0|Rsv|  Index Start  |    Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|0|0|1|0|1|1|      |1|1|0|1|0|0|Rsv|   Type Ext    |  Index Start  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Length     |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|M|0|1|1|0|0|      |0|0|1|1|0|M|Rsv|  Index Start  |  Index Stop   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Length     |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|M|0|1|1|0|1|      |1|0|1|1|0|M|Rsv|   Type Ext    |  Index Start  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Index Stop   |    Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|M|1|1|0|0|0|      |0|0|0|0|1|M|Rsv|            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|M|1|1|0|0|1|      |1|0|0|1|1|M|Rsv|   Type Ext    |    Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Length (cont) |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|0|1|1|0|1|0|      |0|1|0|1|1|0|Rsv|  Index Start  |    Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Length (cont) |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|0|1|1|0|1|1|      |1|1|0|1|1|0|Rsv|   Type Ext    |  Index Start  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Length             |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|M|1|1|1|0|0|      |0|0|1|1|1|M|Rsv|  Index Start  |  Index Stop   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Length             |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Rsv|M|1|1|1|0|1|      |1|0|1|1|1|M|Rsv|   Type Ext    |  Index Start  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Index Stop   |            Length             |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

Appendix E.  Complete Example

   An

   The following example packet, using IPv4 addresses (length (hence address-
   length is four octets) is
   shown.  This packet has a header, indicated by included with the initial octet 0. intent to exemplify how
   packet and message headers are constructed, and how addresses and
   attributes are encoded using address blocks and TLV blocks.  This
   example is specifically not constructed to exhibit maximum message or
   packet size reduction.  Appendix D contains illustrations of all
   syntactical elements.

   The packet header has the phasseqnum bit flag set of its semantics octet 4
   set, flags field set
   (value 8), and hence has version zero, no packet size (this is taken from
   the network or transport protocol carrying this packet), a packet
   sequence number, and Packet Sequence Number, but no packet TLV
   block.

   The packet contains a single message with length 55 54 octets.  This
   message has the mhasorig, mhashoplimit, mhashopcount and mhasseqnum
   bits
   flags of its semantics flags octet 30 set, set (value 240), and hence has version zero and includes an originator address,
   Originator Address, a hop limit, Hop Limit, a hop count Hop Count and a
   message sequence number Message Sequence
   Number (which is type independent).  The message has a message TLV
   block with content length 9 octets, containing a single message TLV.
   This TLV has the thasvalue bit flag of its semantics flags octet 8
   set, set (value 16),
   and hence contains a value Value field, with preceding value length 6
   octets.  The message then has two address blocks each with a
   following address TLV block.

   The first address block contains 2 address prefixes.  It has the
   ahaszerotail and ahassingleprelen bits flags of its semantics flags octet 12 set, set (value
   48), and hence has no head (head length (head-length is zero octets).  It has tail
   length a
   tail-length of 2 octets, hence mid length mid-length is two octets.  The two
   tail octets of each address are not included (since ahaszerotail is
   set) and have value zero.  The address block has a single prefix length. Prefix
   Length.  The following address TLV block is empty (content length 0
   octets).

   The second address block contains 3 addresses.  It has the ahashead
   bit
   flag of its semantics flags octet 1 set, set (value 128), and has head length 2
   octets, no tail (tail length (tail-length is zero octets) and hence mid length mid-length is
   two octets.  It is followed by an address TLV block, with content
   length 9 octets, containing two address block TLVs.  The first of
   these TLVs has the thasvalue bit flag of its semantics flags octet 8 set, set (value 16),
   and has a single value Value of length 2 octets, which applies to all of
   the addresses in the address block.  The second of these TLVs has the
   thasmultiindex bit flag of its
   semantics flags octet 4 set, set (value 32), and hence has
   no value length or value fields.  It has two index fields, fields (Index
   Start and Index Stop), which indicate those addresses this TLV
   applies to (inclusive range, counting from zero).

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0 0|    Packet Sequence Number     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |0 0 0 1  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 1 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1| 0|   Orig Addr   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (cont)           |   Hop Limit   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Count   |    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |0 0 0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 1 0 0 1|   TLV Type    |0 0 0 0 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0|0 0 0 0 0 1 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Value                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Value (cont)          |0 0 0 0 0 0 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0|0 0 1 1 0 0|0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 0|              Mid              |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Mid (cont)   | Prefix Length |0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0|0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 1|0 1|1 0 0 0 0 0 0 1|0 0|0 0 0 0 0 0 1 0|     Head      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Head (cont)  |              Mid              |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Mid (cont)   |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              |0 0 0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 1 0 0 1|   TLV Type    |0 0 0 0 1 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0|0 0 0 0 0 0 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Value             |   TLV Type    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |0 0 1 0 0 0 1 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Index Start  |  Index Stop   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Appendix F.  Contributors

   This specification is the result of the joint efforts of the
   following contributors from the OLSRv2 Design Team, listed
   alphabetically:

   o  Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>

   o  Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr>

   o  Thomas Heide Clausen, LIX, Ecole Polytechnique, France,
      <T.Clausen@computer.org>
   o  Justin W. Dean, NRL, USA<jdean@itd.nrl.navy.mil>

   o  Christopher Dearlove, BAE Systems, UK,
      <chris.dearlove@baesystems.com>

   o  Satoh Hiroki, Hitachi SDL, Japan, <h-satoh.yj@sdl.hitachi.co.jp>
      <hiroki.satoh.yj@sdl.hitachi.co.jp>

   o  Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>

   o  Monden Kazuya, Hitachi SDL, Japan, <monden.vw@sdl.hitachi.co.jp>
      <kazuya.monden.vw@sdl.hitachi.co.jp>

Appendix G.  Acknowledgements  Acknowledgments

   The authors would like to acknowledge the team behind OLSRv1, as
   specified in RFC 3626, OLSR [RFC3626],
   including Anis Laouiti, Laouiti (INT, France), Pascale Minet, Laurent Viennot (all
   (both at INRIA, France), and Amir Qayyum (Center for Advanced
   Research in Engineering, Pakistan) for their contributions.

   The authors would like to gratefully acknowledge the following people
   for intense technical discussions, early reviews and comments on the
   specification and its components: Joe Macker (NRL), components (listed alphabetically):

   o  Brian Adamson (NRL)

   o  Teco Boot (Infinity Networks)

   o  Florent Brunneau (LIX)

   o  Ian Chakeres (Motorola)

   o  Alan Cullen (BAE
   Systems), Ian Chakeres (Motorola), Systems)

   o  Ulrich Herberg (LIX)

   o  Joe Macker (NRL)

   o  Yasunori Owada (Niigata University)

   o  Charlie E. Perkins (Nokia), (WiChorus)

   o  Andreas Schjonhaug (LIX), Florent Brunneau (LIX), Yasunori Owada
   (Niigata University), Teco Boot (Infinity Networks) (LIX)

   and the entire IETF MANET working group.

Authors' Addresses

   Thomas Heide Clausen
   LIX, Ecole Polytechnique, France

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

   Christopher M. Dearlove
   BAE Systems Advanced Technology Centre

   Phone: +44 1245 242194
   EMail: chris.dearlove@baesystems.com
   URI:   http://www.baesystems.com/

   Justin W. Dean
   Naval Research Laboratory

   Phone: +1 202 767 3397
   EMail: jdean@itd.nrl.navy.mil
   URI:   http://pf.itd.nrl.navy.mil/

   Cedric Adjih
   INRIA Rocquencourt

   Phone: +33 1 3963 5215
   EMail: Cedric.Adjih@inria.fr
   URI:   http://menetou.inria.fr/~adjih/

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.