RFC 5444
Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
6. IANA Considerations
This document introduces four namespaces that have been registered: Message Types, Packet TLV Types, Message TLV Types, and Address Block TLV Types. This section specifies IANA registries for these namespaces and provides guidance to the Internet Assigned Numbers Authority regarding registrations in these namespaces. The following terms are used with the meanings defined in [BCP26]: "Namespace", "Assigned Value", "Registration", "Unassigned", "Reserved", "Hierarchical Allocation", and "Designated Expert". The following policies are used with the meanings defined in [BCP26]: "Private Use", "Expert Review", and "Standards Action".6.1. Expert Review: Evaluation Guidelines
For registration requests where an Expert Review is required, the Designated Expert SHOULD take the following general recommendations into consideration: o The purpose of these registries is to support Standard and Experimental MANET routing and related protocols and extensions to these protocols.
o The intention is that all registrations will be accompanied by a
published RFC.
o In order to allow for registration prior to the RFC being approved
for publication, the Designated Expert can approve the
registration once it seems clear that an RFC is expected to be
published.
o The Designated Expert will post a request to the MANET WG mailing
list, or to a successor thereto as designated by the Area
Director, for comments and reviews. This request will include a
reference to the Internet-Draft requesting the registration.
o Before a period of 30 days has passed, the Designated Expert will
either approve or deny the registration request and publish a note
of the decision to the MANET WG mailing list or its successor, as
well as inform IANA and the IESG. A denial note MUST be justified
by an explanation and, in cases where it is possible, suggestions
as to how the request can be modified so as to become acceptable
SHOULD be provided.
For the registry for Message Types, the following guidelines apply:
o Registration of a Message Type implies creation of two registries
for Message-Type-specific Message TLVs and Message-Type-specific
Address Block TLVs. The document that requests the registration
of the Message Type MUST indicate how these Message-Type-specific
TLV Types are to be allocated, from any options in [BCP26], and
any initial allocations. The Designated Expert SHOULD take the
allocation policies specified for these registries into
consideration in reviewing the Message Type allocation request.
For the registries for Packet TLV Types, Message TLV Types, and
Address Block TLV Types, the following guidelines apply:
o These are Hierarchical Allocations, i.e., allocation of a type
creates a registry for the extended types corresponding to that
type. The document that requests the registration of the type
MUST indicate how these extended types are to be allocated, from
any options in [BCP26], and any initial allocations. Normally
this allocation should also undergo Expert Review, but with the
possible allocation of some type extensions as Reserved,
Experimental, and/or Private.
o The request for a TLV Type MUST include the specification of the
permitted size, syntax of any internal structure, and meaning, of
the Value field (if any) of the TLV.
For the registries for Message TLV Types and Address Block TLV Types,
the following additional guidelines apply:
o TLV Type values 0-127 are common for all Message Types. TLVs that
receive registrations from the 0-127 interval SHOULD be modular in
design to allow reuse among protocols.
o TLV Type values 128-223 are Message-Type-specific TLV Type values,
relevant only in the context of the containing Message Type.
Registration of TLV Type values within the 128-223 interval
requires that a registry in the 128-223 interval exists for a
specific Message Type value (see Section 6.2.1), and registrations
are made in accordance with the allocation policies specified for
these Message-Type-specific registries. Message-Type-specific TLV
Types SHOULD be registered for TLVs that the Designated Expert
deems too Message-Type-specific for registration of a 0-127 value.
Multiple different TLV definitions MAY be assigned the same TLV
Type value within the 128-223 interval, given that they are
associated with different Message-Type-specific TLV Type
registries. Where possible, existing global TLV definitions and
modular global TLV definitions for registration in the 0-127 range
SHOULD be used.
6.2. Message Types
A new registry for Message Types has been created, with initial
assignments and allocation policies as specified in Table 6.
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+
Table 6: Message Types
6.2.1. Message-Type-Specific TLV Registry Creation
When a Message Type is registered, then registries MUST be specified
for both Message-Type-specific Message TLVs (Table 8) and Message-
Type-specific Address Block TLVs (Table 10). A document that creates
a Message-Type-specific TLV registry MUST also specify the mechanism
by which Message-Type-specific TLV Types are allocated, from among
those in [BCP26].
6.3. Packet TLV Types
A new registry for Packet TLV Types has been created, with initial assignments and allocation policies as specified in Table 7. +---------+-------------+-------------------+ | Type | Description | Allocation Policy | +---------+-------------+-------------------+ | 0-223 | Unassigned | Expert Review | | 224-255 | Unassigned | Experimental Use | +---------+-------------+-------------------+ Table 7: Packet TLV Types6.3.1. Packet TLV Type Extension Registry Creation
When a Packet TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Packet TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26].6.4. Message TLV Types
A new registry for Message-Type-independent Message TLV Types has been created, with initial assignments and allocation policies as specified in Table 8. +---------+-----------------------+-----------------------+ | Type | Description | Allocation Policy | +---------+-----------------------+-----------------------+ | 0-127 | Unassigned | Expert Review | | 128-223 | Message-Type-specific | Reserved, see Table 9 | | 224-255 | Unassigned | Experimental Use | +---------+-----------------------+-----------------------+ Table 8: Message TLV Types Message TLV Types 128-223 are reserved for Message-Type-specific Message TLVs, for which a new registry is created with the registration of a Message Type, and with initial assignments and allocation policies as specified in Table 9.
+---------+-----------------------------+-------------------+ | Type | Description | Allocation Policy | +---------+-----------------------------+-------------------+ | 0-127 | Common to all Message Types | Reserved | | 128-223 | Message-Type-specific | See Below | | 224-255 | Common to all Message Types | Reserved | +---------+-----------------------------+-------------------+ Table 9: Message-Type-specific Message TLV Types Allocation policies for Message-Type-specific Message TLV Types MUST be specified when creating the registry associated with the containing Message Type, see Section 6.2.1.6.4.1. Message TLV Type Extension Registry Creation
If a Message TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Message TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26].6.5. Address Block TLV Types
A new registry for Message-Type-independent Address Block TLV Types has been created, with initial assignments and allocation policies as specified in Table 10. +---------+-----------------------+------------------------+ | Type | Description | Allocation Policy | +---------+-----------------------+------------------------+ | 0-127 | Unassigned | Expert Review | | 128-223 | Message-Type-specific | Reserved, see Table 11 | | 224-255 | Unassigned | Experimental Use | +---------+-----------------------+------------------------+ Table 10: Address Block TLV Types Address Block TLV Types 128-223 are reserved for Message-Type- specific Address Block TLVs, for which a new registry is created with the registration of a Message Type, and with initial assignments and allocation policies as specified in Table 11.
+---------+-----------------------------+-------------------+ | Type | Description | Allocation Policy | +---------+-----------------------------+-------------------+ | 0-127 | Common to all Message Types | Reserved | | 128-223 | Message-Type-specific | See Below | | 224-255 | Common to all Message Types | Reserved | +---------+-----------------------------+-------------------+ Table 11: Message-Type-specific Address Block TLV Types Allocation policies for Message-Type-specific Address Block TLV Types MUST be specified when creating the registry associated with the containing Message Type, see Section 6.2.1.6.5.1. Address Block TLV Type Extension Registry Creation
When an Address Block TLV Type is registered, then a new registry for type extensions of that type must be created. A document that defines a Message TLV Type MUST also specify the mechanism by which its type extensions are allocated, from among those in [BCP26].7. Security Considerations
This specification does not describe a protocol; it describes a packet format. As such, it does not specify any security considerations; these are matters for a protocol using this specification. However, some security mechanisms are enabled by this specification and may form part of a protocol using this specification. Mechanisms that may form part of an authentication and integrity approach in a protocol using this specification are described in Section 7.1. Mechanisms that may form part of a confidentiality approach in a protocol using this specification are described in Section 7.2. There is, however, no requirement that a protocol using this specification should use either.7.1. Authentication and Integrity Suggestions
The authentication and integrity suggestions made here are based on the intended usage in Appendix B, 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 of messages between neighboring MANET routers in a single transmission and over a single logical hop.
Consequently:
o For forwarded messages where the message is unchanged by
forwarding MANET routers, end-to-end authentication and integrity
MAY be implemented, between MANET routers with an existing
security association, by including a suitable Message TLV
containing a cryptographic signature in the message. Since <msg-
hop-count> and <msg-hop-limit> are the only fields that should be
modified when such a message is forwarded in this manner, this
signature can be calculated based on the entire message, including
the Message Header, with the <msg-hop-count> and <msg-hop-limit>
fields set to 0, if present.
o Hop-by-hop packet level authentication and integrity MAY be
implemented, between MANET routers with an existing security
association, by including a suitable Packet TLV containing a
cryptographic signature to the packet. Since packets are received
as transmitted, this signature can be calculated based on the
entire packet or on parts thereof as appropriate.
7.2. Confidentiality Suggestions
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 to
protect the confidentiality of information included in a Packet,
Message, or Address Block TLV by specifying that the Value field of
that TLV Type be encrypted, as well as specifying the encryption
mechanism.
In an extreme case, all information can be encrypted by defining
either:
o A packet, consisting of only a Packet Header (with no messages)
and containing a Packet TLV, where the Packet TLV Type indicates
that its Value field contains one or more encrypted messages.
Upon receipt, and once this Packet TLV is successfully decrypted,
these messages may then be parsed according to this specification
and processed according to the protocol using this specification.
o A message, consisting of only a Message Header and a single
Message TLV, where the Message TLV Type indicates that its Value
field contains an encrypted version of the message's remaining
Message TLVs, Address Blocks, and Address Block TLVs. Upon
receipt, and once this Message TLV is successfully decrypted, the
complete message may then be parsed according to this
specification and processed according to the protocol using this
specification.
In either case, the protocol MUST define the encrypted TLV Type, as
well as the format of the encrypted data block contained in the Value
field of the TLV.
8. 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, <hiroki.satoh.yj@hitachi.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
9. Acknowledgments
The authors would like to acknowledge the team behind OLSR [RFC3626],
including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot
(both at INRIA, France), and Amir Qayyum (Center for Advanced
Research in Engineering, Pakistan) for their contributions. Elwyn
Davies (Folly Consulting, UK), Lars Eggert (Nokia, Finland), Chris
Newman (Sun Microsystems, USA), Tim Polk (NIST, USA), and Magnus
Westerlund (Ericsson, Sweden) all provided detailed reviews and
insightful comments.
The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews, and comments on the
specification and its components (listed alphabetically):
o Brian Adamson (NRL) o Teco Boot (Infinity Networks) o Florent Brunneau (LIX) o Ian Chakeres (CenGen) o Alan Cullen (BAE Systems) o Ulrich Herberg (LIX) o Joe Macker (NRL) o Yasunori Owada (Niigata University) o Charlie E. Perkins (WiChorus) o Henning Rogge (FGAN) o Andreas Schjonhaug (LIX) and the entire IETF MANET working group.10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC 1/SC22/WG15, "Single UNIX Specification, Version 3, 2004 Edition", April 2004.
10.2. Informative References
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State Routing Protocol", RFC 3626, October 2003. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The Protocols", 1994.
Appendix A. Multiplexing and Demultiplexing
The packet and message format specified in this document is designed to allow zero or more messages to be contained within a single packet. Such messages may be from the same or different protocols. Thus, a multiplexing and demultiplexing process MUST be present. Multiplexing messages on a given MANET router into a single packet, rather than having each message generate its own packet, reduces the total number of octets and the number of packets transmitted by that MANET router. The multiplexing and demultiplexing process running on a given UDP port or IP protocol number, and its associated protocols, MUST: o For each Message Type, a protocol -- unless specified otherwise, the one making the IANA reservation for that Message Type -- MUST be designated as the "owner" of that Message Type. o The Packet Header fields, including the Packet TLV Block, are used by the multiplexing and demultiplexing process, which MAY make such information available for use in its protocol instances. o The <pkt-seq-num> field, if present, contains a sequence number that is incremented by 1 for each packet generated by a node. The sequence number after 65535 is 0. In other words, the sequence number "wraps" in the usual way. o Incoming messages MUST be either silently discarded or MUST be delivered to the instance of the protocol that owns the associated Message Type. Incoming messages SHOULD NOT be delivered to any other protocol instances and SHOULD NOT be delivered to more than one protocol instance. o Outgoing messages of a given type MUST be generated only by the protocol instance that owns that Message Type and be delivered to the multiplexing and demultiplexing process. o If two protocols both wish to use the same Message Type, then this interaction SHOULD be specified by the protocol that is the designated owner of that Message Type.Appendix B. Intended Usage
This appendix describes the intended usage of Message Header fields, including their content and use. Alternative uses of this specification are permitted.
The message format specified in this document is designed to carry
MANET routing protocol signaling between MANET routers and to support
scope-limited flooding as well as point-to-point delivery.
Messages are designed to be able to be forwarded over one or more
logical hops, in a new packet for each logical hop. Each logical hop
may consist of one or more IP hops.
Specifically, scope-limited flooding is supported for messages when:
o The <msg-orig-addr> field, if present, contains the unique
identifier of the MANET router that originated the message.
o The <msg-seq-num> field, if present, contains a sequence number
that starts at 0 when the first message of a given type is
generated by the originator node, and that is incremented by 1 for
each message generated of that type. The sequence number after
65535 is 0. In other words, the sequence number "wraps" in the
usual way.
o If the <msg-orig-addr> and <msg-seq-num> fields are both present,
then the Message Header provides for duplicate suppression, using
the identifier consisting of the message's <msg-orig-addr>, <msg-
seq-num>, and <msg-type>. These serve to uniquely identify the
message in the MANET within the time period until <msg-seq-num> is
repeated, i.e., wraps around to a matching value.
o <msg-hop-limit> field, if present, contains the number of hops on
which the packet is allowed to travel before being discarded by a
MANET router. The <msg-hop-limit> is set by the message
originator and is used to prevent messages from endlessly
circulating in a MANET. When forwarding a message, a MANET router
should decrease the <msg-hop-limit> by 1, and the message should
be discarded when <msg-hop-limit> reaches 0.
o <msg-hop-count> field, if present, contains the number of hops on
which the packet has traveled across the MANET. The <msg-hop-
count> is set to 0 by the message originator and is used to
prevent messages from endlessly circulating in a MANET. When
forwarding a message, a MANET router should increase <msg-hop-
count> by 1 and should discard the message when <msg-hop-count>
reaches 255.
o If the <msg-hop-limit> and <msg-hop-count> fields are both
present, then the Message Header provides the information to make
forwarding decisions for scope-limited flooding. This may be by
any appropriate flooding mechanism specified by a protocol using
this specification.
Appendix C. Examples
This appendix contains some examples of parts of this specification.C.1. Address Block Examples
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 128 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-flags> has ahasfulltail set (value 64); * <head-length> and <head> are omitted.
The Address Block is then 2 64 1 g a b c d e f (10 octets).
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 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 160 1 a 2 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 32 2 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 a b c d n m (9 octets).
C.2. TLV Examples
Assume the definition of an Address Block TLV with type EXAMPLE1 (and
no type extension) that has single octet values per address. There
are a number of ways in which values a, a, b, and c may be associated
with the four addresses in the preceding Address Block, where c is a
default value that can be omitted.
Examples:
o Using one multivalue TLV to cover all of the addresses:
* <tlv-flags> has thasvalue and tismultivalue set (value 20);
* <index-start> and <index-stop> are omitted;
* <length> = 4 (single-length = 1).
* The TLV is then EXAMPLE1 20 4 a a b c (7 octets).
o Using one multivalue TLV and omitting the last address:
* <tlv-flags> has thasmultiindex, thasvalue, and tismultivalue
set (value 52);
* <index-start> = 0;
* <index-stop> = 2;
* <length> = 3 (single-length = 1).
* The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets).
o Using two single value TLVs and 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 1 a (6 octets).
Second:
* <tlv-flags> has thassingleindex and thasvalue set (value 80);
* <index-start> = 2;
* <index-stop> is omitted;
* <length> = 1;
* <value> = b.
* The TLV is then EXAMPLE1 80 2 1 b (5 octets).
Total length of TLVs is 11 octets.
In this case, the first of these is the most efficient. In other
cases, patterns such as the others may be preferred. Regardless of
efficiency, any of these may be used.
Assume the definition of an Address Block TLV with type EXAMPLE2 (and
no type extension) that has no value and that is to be associated
with the second and third addresses in an Address Block. 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 (4 octets). Assume the definition of a Message TLV with type EXAMPLE3 (and no type extension) that 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 + N octets, where N is the number of data octets (it can be 3 + N octets if N is 255 or less).
(page 34 continued on part 3)
