draft-ietf-manet-rfc5444-usage-04.txt   draft-ietf-manet-rfc5444-usage-05.txt 
Network Working Group T. Clausen Network Working Group T. Clausen
Internet-Draft Ecole Polytechnique Internet-Draft Ecole Polytechnique
Updates: 5444 (if approved) C. Dearlove Updates: 5444 (if approved) C. Dearlove
Intended status: Standards Track BAE Systems Intended status: Standards Track BAE Systems
Expires: November 5, 2016 U. Herberg Expires: October 14, 2017 U. Herberg
H. Rogge H. Rogge
Fraunhofer FKIE Fraunhofer FKIE
May 4, 2016 April 12, 2017
Rules For Designing Protocols Using the RFC 5444 Generalized Packet/ Rules For Designing Protocols Using the RFC 5444 Generalized Packet/
Message Format Message Format
draft-ietf-manet-rfc5444-usage-04 draft-ietf-manet-rfc5444-usage-05
Abstract Abstract
RFC 5444 specifies a generalized MANET packet/message format and RFC 5444 specifies a generalized MANET packet/message format and
describes an intended use to multiplex MANET routing protocol describes an intended use to multiplex MANET routing protocol
messages that is mandated for use by RFC 5498. This document updates messages that is mandated for use on the port/protocol specified by
RFC 5444 by providing rules and recommendations for how the RFC 5498. This document updates RFC 5444 by providing rules and
multiplexer operates and how protocols can use the packet/message recommendations for how the multiplexer operates and how protocols
format. In particular, the mandatory rules prohibit a number of uses can use the packet/message format. In particular, the mandatory
of RFC 5444 that have been suggested in various proposals, and which rules prohibit a number of uses that have been suggested in various
would have led to interoperability problems, to the impediment of proposals, and which would have led to interoperability problems, to
protocol extension development, and to an inability to use optional the impediment of protocol extension development, and to an inability
generic RFC 5444 parsers. to use optional generic parsers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 5, 2016. This Internet-Draft will expire on October 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. History and Purpose . . . . . . . . . . . . . . . . . . . 3 1.1. History and Purpose . . . . . . . . . . . . . . . . . . . 3
1.2. RFC 5444 Features . . . . . . . . . . . . . . . . . . . . 3 1.2. RFC 5444 Features . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Packet/Message Format . . . . . . . . . . . . . . . . 4 1.2.1. Packet/Message Format . . . . . . . . . . . . . . . . 4
1.2.2. Multiplexing and Demultiplexing . . . . . . . . . . . 6 1.2.2. Multiplexing and Demultiplexing . . . . . . . . . . . 6
1.3. Status of This Document . . . . . . . . . . . . . . . . . 6 1.3. Status of This Document . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
4. Information Transmission . . . . . . . . . . . . . . . . . . . 7 4. Information Transmission . . . . . . . . . . . . . . . . . . . 8
4.1. Where to Record Information . . . . . . . . . . . . . . . 7 4.1. Where to Record Information . . . . . . . . . . . . . . . 8
4.2. Message Multiplexing and Packets . . . . . . . . . . . . . 9 4.2. Message and TLV Type Allocation . . . . . . . . . . . . . 8
4.3. Messages, Addresses and Attributes . . . . . . . . . . . . 11 4.3. Message Recognistion . . . . . . . . . . . . . . . . . . . 9
4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 12 4.4. Message Multiplexing and Packets . . . . . . . . . . . . . 10
4.5. Information Representation . . . . . . . . . . . . . . . . 14 4.4.1. Packet Transmission . . . . . . . . . . . . . . . . . 10
4.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4.2. Packet Reception . . . . . . . . . . . . . . . . . . . 11
4.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 15 4.5. Messages, Addresses and Attributes . . . . . . . . . . . . 13
5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.6. Addresses Require Attributes . . . . . . . . . . . . . . . 13
6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 17 4.7. Information Representation . . . . . . . . . . . . . . . . 16
6.1. Address Block Compression . . . . . . . . . . . . . . . . 17 4.8. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.9. Message Integrity . . . . . . . . . . . . . . . . . . . . 17
6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6.1. Address Block Compression . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
[RFC5444] specifies a generalized packet/message format, designed for [RFC5444] specifies a generalized packet/message format, designed for
use by MANET routing protocols. use by MANET routing protocols.
[RFC5444] was designed following experiences with [RFC3626], which [RFC5444] was designed following experiences with [RFC3626], which
attempted, but did not quite succeed in, providing a packet/message attempted, but did not quite succeed in, providing a packet/message
format accommodating for diverse protocol extensions. [RFC5444] was format accommodating for diverse protocol extensions. [RFC5444] was
designed as a common building block for use by both proactive and designed as a common building block for use by both proactive and
skipping to change at page 6, line 8 skipping to change at page 6, line 8
time). time).
o It contains a minimal Message Header (a maximum of five elements: o It contains a minimal Message Header (a maximum of five elements:
type, originator, sequence number, hop count and hop limit) that type, originator, sequence number, hop count and hop limit) that
permit decisions whether to locally process a message, or forward permit decisions whether to locally process a message, or forward
a message (thus enabling MANET-wide flooding of a message) without a message (thus enabling MANET-wide flooding of a message) without
processing the body of the message. processing the body of the message.
1.2.2. Multiplexing and Demultiplexing 1.2.2. Multiplexing and Demultiplexing
The multiplexer (and demultiplexer) is defined in Appendix A of
[RFC5444]. Its purpose is to allow multiple protocols to shared the
same IP protocol or UDP port. That sharing was made necessary by the
separation of [RFC6130] from [RFC7181] as separate protocols, and by
the allocation of a single IP protocol and UDP port to all MANET
protocols, including those protocols, following [RFC5498], which
states that "All interoperable protocols running on these well-known
IANA allocations MUST conform to [RFC5444]. [RFC5444] provides a
common format that enables one or more protocols to share the IANA
allocations defined in this document unambiguously.". The
multiplexer is the mechanism in [RFC5444] that enables that sharing.
The primary purposes of the multiplexer are to: The primary purposes of the multiplexer are to:
o Accept messages from MANET protocols, which also indicate over o Accept messages from MANET protocols, which also indicate over
which interface(s) the messages are to be sent, and to which which interface(s) the messages are to be sent, and to which
destination address. The latter may be a unicast address or the destination address. The latter may be a unicast address or the
"LL-MANET-Routers" link local multicast address defined in "LL-MANET-Routers" link local multicast address defined in
[RFC5498]. [RFC5498].
o Collect messages, possibly from multiple protocols, for the same o Collect messages, possibly from multiple protocols, for the same
interface and destination, into packets to be sent one logical interface and destination, into packets to be sent one logical
skipping to change at page 6, line 36 skipping to change at page 6, line 48
relationships, for example as extensions, this is the responsibility relationships, for example as extensions, this is the responsibility
of the protocols. For example OLSRv2 [RFC7181] extends the HELLO of the protocols. For example OLSRv2 [RFC7181] extends the HELLO
messages created by NHDP [RFC6130]. However the multiplexer will messages created by NHDP [RFC6130]. However the multiplexer will
deliver HELLO messages to NHDP and will expect to receive HELLO deliver HELLO messages to NHDP and will expect to receive HELLO
messages from NHDP, the relationship between NHDP and OLSRv2 is messages from NHDP, the relationship between NHDP and OLSRv2 is
between those two protocols. between those two protocols.
The multiplexer is also responsible for the Packet Header, including The multiplexer is also responsible for the Packet Header, including
any Packet Sequence Number and Packet TLVs. It may accept some any Packet Sequence Number and Packet TLVs. It may accept some
additional instructions from protocols, pass additional information additional instructions from protocols, pass additional information
to protocols, and must follow some additional rules, see Section 4.2. to protocols, and must follow some additional rules, see Section 4.4.
1.3. Status of This Document 1.3. Status of This Document
This document updates [RFC5444], and is intended for publication as a This document updates [RFC5444], and is intended for publication as a
Proposed Standard (rather than as Informational) because it specifies Proposed Standard (rather than as Informational) because it specifies
and mandates constraints on the use of [RFC5444] which, if not and mandates constraints on the use of [RFC5444] which, if not
followed, makes forms of extensions of those protocols impossible, followed, makes forms of extensions of those protocols impossible,
impedes the ability to generate efficient messages, or makes impedes the ability to generate efficient messages, or makes
desirable forms of generic parsers impossible. desirable forms of generic parsers impossible.
skipping to change at page 7, line 37 skipping to change at page 8, line 4
This document does not specify a protocol, but documents constraints This document does not specify a protocol, but documents constraints
on how to design protocols that are using the generic packet/message on how to design protocols that are using the generic packet/message
format defined in [RFC5444] which, if not followed, makes forms of format defined in [RFC5444] which, if not followed, makes forms of
extensions of those protocols impossible, impedes the ability to extensions of those protocols impossible, impedes the ability to
generate efficient (small) messages, or makes desirable forms of generate efficient (small) messages, or makes desirable forms of
generic parsers impossible. The use of the [RFC5444] format is generic parsers impossible. The use of the [RFC5444] format is
mandated by [RFC5498] for all protocols running over the manet mandated by [RFC5498] for all protocols running over the manet
protocol and port, defined therein. Thus, the constraints in this protocol and port, defined therein. Thus, the constraints in this
document apply to all protocols running over the manet protocol and document apply to all protocols running over the manet protocol and
port. port. The constraints are strongly recommended for other uses of
[RFC5444].
4. Information Transmission 4. Information Transmission
Protocols need to transmit information from one instance implementing Protocols need to transmit information from one instance implementing
the protocol to another. the protocol to another.
4.1. Where to Record Information 4.1. Where to Record Information
A protocol has the following choices as to where to put information A protocol has the following choices as to where to put information
for transmission: for transmission:
skipping to change at page 8, line 22 skipping to change at page 8, line 34
is to be carried one hop. It SHOULD only be used either where the is to be carried one hop. It SHOULD only be used either where the
information relates to the packet as a whole (for example packet information relates to the packet as a whole (for example packet
integrity check values and timestamps, as specified in [RFC7182]) or integrity check values and timestamps, as specified in [RFC7182]) or
if the information is of expected wider application than a single if the information is of expected wider application than a single
protocol. A protocol can also request that the Packet Header include protocol. A protocol can also request that the Packet Header include
Packet Sequence Numbers, but does not control those numbers. Packet Sequence Numbers, but does not control those numbers.
The second case (in a message of a type owned by another protocol) is The second case (in a message of a type owned by another protocol) is
only possible if the adding protocol is an extension to the owning only possible if the adding protocol is an extension to the owning
protocol; for example OLSRv2 [RFC7181] is an extension of NHDP protocol; for example OLSRv2 [RFC7181] is an extension of NHDP
[RFC6130]. While this is not the most common case, protocols SHOULD [RFC6130].
be designed to enable this to be possible, and some of the rules in
this document are to help facilitate that. An extension to The third case is the normal case for a new protocol.
A protocol extension may be either an update of the protocol (the
third case) or a new protocol (the second case). An extension to
[RFC5444], such as [RFC7182], is considered to be an extension to all [RFC5444], such as [RFC7182], is considered to be an extension to all
protocols in this regard. protocols. Protocols SHOULD be designed to enable extension by any
of these means to be possible, and some of the rules in this document
(in particular on Section 4.6 and xref target="integrity"/>) are to
help facilitate that.
The third case is the normal case for a new protocol. Protocols MUST 4.2. Message and TLV Type Allocation
be conservative in the number of new Message Types that they require,
as the total available number of allocatable Message Types is only Protocols SHOULD be conservative in the number of new Message Types
224. Protocol design SHOULD consider whether different functions can that they require, as the total available number of allocatable
be implemented by differences in TLVs carried in the same Message Message Types is only 224. Protocol design SHOULD consider whether
Type, rather than using multiple Message Types. If a protocol's different functions can be implemented by differences in TLVs carried
needs can be covered by use of the second case, then this SHOULD be in the same Message Type, rather than using multiple Message Types.
done.
The TLV type space, although greater than the Message Type space, The TLV type space, although greater than the Message Type space,
SHOULD also be used efficiently. The Full Type of a TLV occupies two SHOULD also be used efficiently. The Full Type of a TLV occupies two
octets, thus there are many more available TLV Full Types than there octets, thus there are many more available TLV Full Types than there
are Message Types. However, in some cases (currently LINK_METRIC are Message Types. However, in some cases (currently LINK_METRIC
from [RFC7181] and ICV and TIMESTAMP from [RFC7182], all in the from [RFC7181] and ICV and TIMESTAMP from [RFC7182], all in the
global TLV type space) a TLV Type with a complete set of 256 TLV Full global TLV type space) a TLV Type with a complete set of 256 TLV Full
Types is defined (but not necessarily allocated). Types is defined (but not necessarily allocated).
Each Message Type has an associated block of Message-Type-specific Each Message Type has an associated block of Message-Type-specific
TLV Types (128 to 233, each of with 256 type extensions), both for TLV Types (128 to 233, each of with 256 type extensions), both for
Address Block TLV Types and Message TLV Types. TLV Types from within Address Block TLV Types and Message TLV Types. TLV Types from within
these blocks SHOULD be used in preference to the Message-Type- these blocks SHOULD be used in preference to the Message-Type-
independent Message TLV Types (0 to 127, each with 256 type independent Message TLV Types (0 to 127, each with 256 type
extensions) when a TLV is specific to a message. extensions) when a TLV is specific to a message.
The Expert Review guidelines in [RFC5444] are updated to include the
general requirement that:
o The Designated Expert will consider the limited TLV and,
especially, Message Type space in considering whether a requested
allocation is allowed, and whether a more efficient allocation
than that requested is possible.
4.3. Message Recognistion
A message contains a Message Header and a Message Body; note that the A message contains a Message Header and a Message Body; note that the
Message TLV Block is considered as part of the latter. The Message Message TLV Block is considered as part of the latter. The Message
Header contains information whose primary purpose is to decide Header contains information whose primary purpose is to decide
whether to process the message, and whether to forward the message. whether to process the message, and whether to forward the message.
A message MUST be recognized by the combination of its Message Type, A message can be recognized as one that has been previously seen
Originator Address and Message Sequence Number. This allows each (which may determine whether it is processed and/or forwarded) if it
protocol to manage its own Message Sequence Numbers, and also allows contains sufficient information in its Message Header. A message
for the possibility that different Message Types may have greatly MUST be so recognized by the combination of all three of its Message
differing transmission rates. [RFC7181] contains a general purpose Type, Originator Address and Message Sequence Number. The inclusion
process for managing processing and forwarding decisions, albeit one of Message Type allows each protocol to manage its own Message
presented as for use with MPR flooding. (Blind flooding can be Sequence Numbers, and also allows for the possibility that different
handled similarly by assuming that all other routers are MPR Message Types may have greatly differing transmission rates. As an
selectors; it is not necessary in this case to differentiate between example of such use, [RFC7181] contains a general purpose process for
interfaces on which a message is received.) managing processing and forwarding decisions, albeit one presented as
for use with MPR flooding. (Blind flooding can be handled similarly
by assuming that all other routers are MPR selectors; it is not
necessary in this case to differentiate between interfaces on which a
message is received.)
Most protocol information is thus contained in the Message Body. A Most protocol information is thus contained in the Message Body. A
model of how such information may be viewed is described in model of how such information may be viewed is described in
Section 4.3 and Section 4.4. To use that model, addresses (for Section 4.5 and Section 4.6. To use that model, addresses (for
example of neighboring or otherwise known routers) SHOULD be recorded example of neighboring or otherwise known routers) SHOULD be recorded
in Address Blocks, not as data in TLVs. Recording addresses in TLV in Address Blocks, not as data in TLVs. Recording addresses in TLV
Value fields both breaks the model of addresses as identities and Value fields both breaks the model of addresses as identities and
associated information (attributes) and also inhibits address associated information (attributes) and also inhibits address
compression. However in some cases alternative addresses (e.g., compression. However in some cases alternative addresses (e.g.,
hardware addresses when the Address Block is recording IP addresses) hardware addresses when the Address Block is recording IP addresses)
MAY be carried as TLV Values. Note that a message contains a Message MAY be carried as TLV Values. Note that a message contains a Message
Address Length field that can be used to allow carrying alternative Address Length field that can be used to allow carrying alternative
message sizes, but only one length of addresses can be used in a message sizes, but only one length of addresses can be used in a
single message, in all Address Blocks and the Originator Address, and single message, in all Address Blocks and the Originator Address, and
is established by the router and protocol generating the message. is established by the router and protocol generating the message.
4.2. Message Multiplexing and Packets 4.4. Message Multiplexing and Packets
The multiplexer has to handle message multiplexing into packets and The multiplexer has to handle message multiplexing into packets and
their transmission, and packet reception and demultiplexing into their transmission, and packet reception and demultiplexing into
messages. The multiplexer and the protocols that use it are subject messages. The multiplexer and the protocols that use it are subject
to the following rules. to the following rules.
4.4.1. Packet Transmission
Packets are formed for transmission by: Packets are formed for transmission by:
o Outgoing messages are created by their owning protocol, and MAY be o Outgoing messages are created by their owning protocol, and MAY be
modified by any extending protocols if the owning protocol permits modified by any extending protocols if the owning protocol permits
this. Messages MAY also be forwarded by their owning protocol. this. Messages MAY also be forwarded by their owning protocol.
It is strongly RECOMMENDED that messages are not modified in the It is strongly RECOMMENDED that messages are not modified in the
latter case, other than to their hop count and hop limit fields. latter case, other than to their hop count and hop limit fields.
This is because it enables authentication using [RFC7182], which Note that this includes having an identical octet representation,
ignores (zeros) those two fields (only) for its end to end Message including not allowing a different TLV representation of the same
TLV ICV (Integrity Check Value) calculations. informnation. This is because it enables end to end
authentication that ignores (zeros) those two fields (only), as is
done by for the Message TLV ICV (Integrity Check Value)
calculations in [RFC7182]. Prototols are strongly RECOMMENDED to
document their behavior with regard to modifiability of messages.
o Outgoing messages are then sent to the multiplexer. The owning o Outgoing messages are then sent to the multiplexer. The owning
protocol MUST indicate which interface(s) the messages are to be protocol MUST indicate which interface(s) the messages are to be
sent on and their destination address, and MAY request that sent on and their destination address. Note that packets travel
messages are kept together in a packet; the multiplexer SHOULD one hop; the destination is therefore either a link local
respect this request if at all possible. multicast address, if the packet is being multicast, or the
address of the neighbor interface to which the packet is sent.
o The multiplexer SHOULD combine messages from multiple protocols o The owning protocol MAY request that messages are kept together in
that are sent on the same interface in a packet, provided that in a packet; the multiplexer SHOULD respect this request if at all
so doing the multiplexer does not cause an IP packet to exceed the possible. The multiplexer SHOULD combine messages that are sent
current MTU (Maximum Transmission Unit). Note that the on the same interface in a packet, whether from the same of
multiplexer cannot fragment messages; creating suitable sized different protocols, provided that in so doing the multiplexer
messages that will not cause the MTU to be exceeded if sent in a does not cause an IP packet to exceed the current MTU (Maximum
single message packet is the responsibility of the protocol Transmission Unit). Note that the multiplexer cannot fragment
generating the message. If a larger message is created then only messages; creating suitable sized messages that will not cause the
IP fragmentation is available to allow the packet to be sent, and MTU to be exceeded if sent in a single message packet is the
this is generally considered undesirable, especially when responsibility of the protocol generating the message. If a
transmission may be unreliable. larger message is created then only IP fragmentation is available
to allow the packet to be sent, and this is generally considered
undesirable, especially when transmission may be unreliable.
o The multiplexer MAY delay messages briefly in order to assemble o The multiplexer MAY delay messages in order to assemble more
more efficient packets. It SHOULD respect any constraints on such efficient packets. It MUST respect any constraints on such delays
delays requested by the protocol. requested by the protocol if it is practical to do so.
o If requested by a protocol, the multiplexer SHOULD, and otherwise o If requested by a protocol, the multiplexer MUST, and otherwise
MAY, include a Packet Sequence Number in the packet. Note that, MAY, include a Packet Sequence Number in the packet. Such a
as per the errata to [RFC5444], this Packet Sequence Number MUST request MUST be respected as long as the protocol is active. Note
be specific to the interface on which the packet is sent. that the errata to [RFC5444], indicates that the Packet Sequence
Separate sequence numbers MUST be maintained for each destination Number SHOULD be specific to the interface on which the packet is
sent. This specification updates [RFC5444] by requiring that this
sequence number MUST be specific to that interface and also that
separate sequence numbers MUST be maintained for each destination
to which packets are sent with included Packet Sequence Numbers. to which packets are sent with included Packet Sequence Numbers.
(Note that packets travel one hop; the destination is therefore Addition of Packet Sequence Numbers MUST be consistent, i.e., for
either a link local multicast address, if the packet is being each interface and destination the Packet Sequence Number MUST be
multicast, or the address of the neighbor interface to which the added to all packets or to none.
packet is sent.) Addition of Packet Sequence Numbers MUST be
consistent, i.e., for each interface and destination the Packet
Sequence Number MUST be added to all packets or to none.
o An extension to the multiplexer MAY add TLVs to the packet and/or o An extension to the multiplexer MAY add TLVs to the packet. It
the messages. For example [RFC7182] MAY be used by the may also add TLVs to the messages, in which case it is considered
multiplexer to add Packet TLVs or Message TLVs, or by the protocol as also extended the corresponding protocols. For example
to add Message TLVs. (Whether [RFC7182] Message TLVs are added [RFC7182] can be used by the multiplexer to add Packet TLVs or
and verified by the multiplexer or by the protocol is an Message TLVs, or by the protocol to add Message TLVs.
implementation detail.)
When a packet is received, the following steps are required to be 4.4.2. Packet Reception
performed by the demultiplexer:
o The packet and/or the messages it contains MAY be verified by an When a packet is received, the following steps are performed by the
extension to the demultiplexer, such as [RFC7182]. demultiplexer and by protocols:
o Each message MUST be sent to its owning protocol. The o The Packet Header and the organisation into the messages that it
demultiplexer MUST also make the Packet Header, and the source and contains MUST be verified by the demultiplexer.
destination addresses in the IP datagram that included the packet,
available to the protocol.
o The demultiplexer MUST remove any TLVs added to the message by the o The packet and/or the messages it contains MAY also be verified by
multiplexer. The message MUST be passed on to the protocol an extension to the demultiplexer, such as [RFC7182].
exactly as received from (another instance of) the protocol.
o The owning protocol SHOULD verify each message for correctness, it o Each message MUST be sent to its owning protocol, or discarded if
SHOULD allow any extending protocol(s) to also contribute to this the Message Type is not recognized. The demultiplexer MUST also
make the Packet Header, and the source and destination addresses
in the IP datagram that included the packet, available to the
protocol.
o The demultiplexer MUST remove any Message TLVs that were added by
an extension to the multiplexer. The message MUST be passed on to
the protocol exactly as received from (another instance of) the
protocol. This is in part an implementation detail. For example
an implementation of [RFC7182] could add Message TLV either in the
multiplexer or in the protocol; an implemention MUST ensure that
the message passed to a protocol is as it would be passed from
that protocol by this implementation.
o The owning protocol MUST verify each message for correctness, it
MUST allow any extending protocol(s) to also contribute to this
verification. verification.
o The owning protocol MUST process each message, or make an informed o The owning protocol MUST process each message. In some cases,
decision not to do so. In the former case an owning protocol that which will be defined in the protocol specification, this
permits this MUST allow any extending protocols to process or processing will determine that the message MUST be ignored.
ignore the message. Except in the latter case, the owning protocol MUST also allow any
extending protocols to process the message.
o The owning protocol is responsible for managing the hop count o The owning protocol MUST manage the hop count and/or hop limit in
and/or hop limit in the message. It is RECOMMENDED that these are the message. It is RECOMMENDED that these are handled as
handled as described in Appendix B of [RFC5444]; they MUST be so described in Appendix B of [RFC5444]; they MUST be so handled if
handled if using hop count dependent TLVs such as those defined in using hop count dependent TLVs such as those defined in [RFC5497].
[RFC5497].
4.3. Messages, Addresses and Attributes 4.4.2.1. Other Information
In addition to the messages between the multiplexer and the protocols
in each direction, the following additional information, summarised
from other sections in this specification, can be exchanged.
o The packet source and destination addresses MUST be sent from
(de)multiplexer to protocol.
o The Packet Header, including packet sequence number, MUST be sent
from (de)multiplexer to protocol if present. (An implementation
may choose to only do so, or only report the packet sequence
number, on request.)
o A protocol MAY require that all outgoing packets contain a packet
sequence number.
o The interface over which a message is to be sent and its
destination address MUST be sent from protocol to multiplexer.
The destination address may be a multicast address, in particular
the LL-MANET-Routers link-local multicast address defined in
[RFC5498].
o A request to keep messages together in one packet MAY be sent from
protocol to multiplexer.
o A requested maximum message delay MAY be sent from protocol to
multiplexer.
The protocol SHOULD also be aware of the MTU that will apply to its
messages, if this is available.
4.5. Messages, Addresses and Attributes
The information in a Message Body, including Message TLVs and Address The information in a Message Body, including Message TLVs and Address
Block TLVs, can be considered to consist of: Block TLVs, can be considered to consist of:
o Attributes of the message, each attribute consisting of a Full o Attributes of the message, each attribute consisting of a Full
Type, a length, and a Value (of that length). Type, a length, and a Value (of that length).
o A set of addresses, carried in one or more Address Blocks. o A set of addresses, carried in one or more Address Blocks.
o Attributes of each address, each attribute consisting of an Full o Attributes of each address, each attribute consisting of an Full
Type, a length, and a Value (of that length). Type, a length, and a Value (of that length).
Attributes are carried in TLVs. For Message TLVs the mapping from Attributes are carried in TLVs. For Message TLVs the mapping from
TLV to attribute is one to one. For Address Block TLVs the mapping TLV to attribute is one to one. For Address Block TLVs the mapping
from TLV to attribute is one to many: one TLV can carry attributes from TLV to attribute is one to many: one TLV can carry attributes
for multiple addresses, but only one attribute per address. for multiple addresses, but only one attribute per address.
Attributes for different addresses may be the same or different. Attributes for different addresses may be the same or different.
A TLV Full Type MAY be (and this is RECOMMENDED whenever possible) It is RECOMMENDED that a TLV Full Type MAY be defined so that there
defined so that there MUST only be one TLV of that Full Type MUST only be one TLV of that Full Type associated with the packet
associated with the packet (Packet TLV), message (Message TLV), or (Packet TLV), message (Message TLV), or any value of any address
any value of any address (Address Block TLV). Note that an address (Address Block TLV). Note that an address may appear more than once
may appear more than once in a message, but the restriction on in a message, but the restriction on associating TLVs with addresses
associating TLVs with addresses covers all copies of that address. covers all copies of that address. It is RECOMMENDED that addresses
It is RECOMMENDED that addresses are not repeated in a message. are not repeated in a message.
4.4. Addresses Require Attributes 4.6. Addresses Require Attributes
It is not mandatory in [RFC5444] to associate an address with It is not mandatory in [RFC5444] to associate an address with
attributes using Address Block TLVs. Information about an address attributes using Address Block TLVs. Information about an address
could thus, in principle, be carried using: could thus, in principle, be carried using:
o The simple presence of an address. o The simple presence of an address.
o The ordering of addresses in an Address Block. o The ordering of addresses in an Address Block.
o The use of different meanings for different Address Blocks. o The use of different meanings for different Address Blocks.
skipping to change at page 13, line 10 skipping to change at page 14, line 48
demultiplexer, which also MUST NOT reject a packet based on an demultiplexer, which also MUST NOT reject a packet based on an
unrecognized message; although it will reject any such messages, unrecognized message; although it will reject any such messages,
it MUST deliver any other messages in the packet to their owning it MUST deliver any other messages in the packet to their owning
protocols. protocols.
The following points indicate the reasons for these rules, based on The following points indicate the reasons for these rules, based on
considerations of extensibility and efficiency. considerations of extensibility and efficiency.
Assigning a meaning to the presence, absence or location, of an Assigning a meaning to the presence, absence or location, of an
address would reduce the extensibility of the protocol, prevent the address would reduce the extensibility of the protocol, prevent the
approach to information representation described in Section 4.5, and approach to information representation described in Section 4.7, and
reduce the options available for message optimization described in reduce the options available for message optimization described in
Section 6. Section 6.
To consider how the simple presence of an address conveying To consider how the simple presence of an address conveying
information would have restricted the development of an extension, information would have restricted the development of an extension,
two examples, one actual (included in the base specification, but two examples, one actual (included in the base specification, but
could have been added later) and one hypothetical, are considered. could have been added later) and one hypothetical, are considered.
The basic function of NHDP's HELLO messages [RFC6130] is to indicate The basic function of NHDP's HELLO messages [RFC6130] is to indicate
that addresses are of neighbors, using the LINK_STATUS and that addresses are of neighbors, using the LINK_STATUS and
skipping to change at page 14, line 17 skipping to change at page 16, line 7
The creation of Multi-Topology OLSRv2 (MT-OLSRv2) [RFC7722], as an The creation of Multi-Topology OLSRv2 (MT-OLSRv2) [RFC7722], as an
extension to OLSRv2 that can interoperate with unextended instances extension to OLSRv2 that can interoperate with unextended instances
of OLSRv2, would not have been possible without these restrictions, of OLSRv2, would not have been possible without these restrictions,
which were applied to NHDP and OLSRv2 by [RFC7181]. which were applied to NHDP and OLSRv2 by [RFC7181].
These restrictions do not, however, mean that added information is These restrictions do not, however, mean that added information is
completely ignored for purposes of the base protocol. Suppose that a completely ignored for purposes of the base protocol. Suppose that a
faulty implementation of OLSRv2 (including NHDP) creates a HELLO faulty implementation of OLSRv2 (including NHDP) creates a HELLO
message that assigns two different values of the same link metric to message that assigns two different values of the same link metric to
an address, something that is not permitted by [RFC7181]. A an address, something that is not permitted by [RFC7181]. A
receiving OLSRv2-aware implementation of NHDP MUST reject such a receiving OLSRv2-aware implementation of NHDP will reject such a
message, even though a receiving OLSRv2-unaware implementation of message, even though a receiving OLSRv2-unaware implementation of
NHDP will process it. This is because the OLSRv2-aware NHDP will process it. This is because the OLSRv2-aware
implementation has access to additional information, that the HELLO implementation has access to additional information, that the HELLO
message is definitely invalid, and the message is best ignored, as it message is definitely invalid, and the message is best ignored, as it
is unknown what other errors it may contain. is unknown what other errors it may contain.
4.5. Information Representation 4.7. Information Representation
This section describes a conceptual way to consider the information This section describes a conceptual way to consider the information
in a message. It may be used as the basis of an approach to parsing, in a message. It may be used as the basis of an approach to parsing,
or creating, a message to, or from, the information that it contains, or creating, a message to, or from, the information that it contains,
or is to contain. However there is no requirement that a protocol or is to contain. However there is no requirement that a protocol
does so. This approach may be used either to inform a protocol does so. This approach may be used either to inform a protocol
design, or by a protocol (or generic parser) implementer. design, or by a protocol (or generic parser) implementer.
A message (excluding the Message Header) can be represented by two, A message (excluding the Message Header) can be represented by two,
possibly multivalued, maps: possibly multivalued, maps:
skipping to change at page 15, line 21 skipping to change at page 17, line 11
o Input: Full Type. Output: list of (address, length, Value) o Input: Full Type. Output: list of (address, length, Value)
triples. As this list length may be significant, a possible triples. As this list length may be significant, a possible
output will be of one or two iterators that will allow iterating output will be of one or two iterators that will allow iterating
through that list. (One iterator that can detect the end of list, through that list. (One iterator that can detect the end of list,
or a pair of iterators specifying a range.) or a pair of iterators specifying a range.)
Additional differences in the interface may relate to, for example, Additional differences in the interface may relate to, for example,
the ordering of output lists. the ordering of output lists.
4.6. TLVs 4.8. TLVs
Within a message, the attributes are represented by TLVs. Within a message, the attributes are represented by TLVs.
Particularly for Address Block TLVs, different TLVs may represent the Particularly for Address Block TLVs, different TLVs may represent the
same information. For example, using the LINK_STATUS TLV defined in same information. For example, using the LINK_STATUS TLV defined in
[RFC6130], if some addresses have Value SYMMETRIC and some have Value [RFC6130], if some addresses have Value SYMMETRIC and some have Value
HEARD, arranged in that order, then this information can be HEARD, arranged in that order, then this information can be
represented using two single value TLVs or one multivalue TLV. The represented using two single value TLVs or one multivalue TLV. The
latter can be used even if the addresses are not so ordered. latter can be used even if the addresses are not so ordered.
A protocol MAY use any representation of information using TLVs that A protocol MAY use any representation of information using TLVs that
convey the required information. A protocol SHOULD use an efficient convey the required information. A protocol SHOULD use an efficient
representation, but this is a quality of implementation issue. A representation, but this is a quality of implementation issue. A
protocol MUST recognize any permitted representation of the protocol MUST recognize any permitted representation of the
information; even if it chooses to (for example) only use multivalue information; even if it chooses to (for example) only use multivalue
TLVs, it MUST recognize single value TLVs (and vice versa). TLVs, it must recognize single value TLVs (and vice versa).
A protocol defining new TLVs MUST respect the naming and A protocol defining new TLVs MUST respect the naming and
organizational rules in [RFC7631]. It SHOULD follow the guidance in organizational rules in [RFC7631]. It SHOULD follow the guidance in
[RFC7188], except where those requirements are ones that MUST be [RFC7188], in particular see Section 6.3. (This specification does
followed as required by this specification (or when extending not however relax the application of [RFC7188] where it is mandated.)
[RFC6130] or [RFC7181], when these MUST also be followed).
4.7. Message Integrity 4.9. Message Integrity
In addition to not rejecting a message due to unknown TLVs or TLV In addition to not rejecting a message due to unknown TLVs or TLV
Values, a protocol MUST NOT fail to forward a message (by whatever Values, a protocol MUST NOT reject a message based on the inclusion
means of message forwarding are appropriate to that protocol) due to of a TLV of an unrecognized type. The protocol MUST ignore any such
the presence of such TLVs or TLV Values, and MUST NOT remove such TLVs when processing the message. The protocol MUST NOT remove or
TLVs or TLV Values. Such behavior would have the consequences that: change any such TLVs if the message is to be forwarded unchanged.
Such behavior would have the consequences that:
o It might disrupt the operation of an extension of which it is o It might disrupt the operation of an extension of which it is
unaware. Note that it is the responsibility of a protocol unaware. Note that it is the responsibility of a protocol
extension to handle interoperation with unextended instances of extension to handle interoperation with unextended instances of
the protocol. For example OLSRv2 [RFC7181] adds an MPR_WILLNG TLV the protocol. For example OLSRv2 [RFC7181] adds an MPR_WILLNG TLV
to HELLO messages (created by NHDP, [RFC6130], of which it is in to HELLO messages (created by NHDP, [RFC6130], of which it is in
part an extension) to recognize this case (and for other reasons). part an extension) to recognize this case (and for other reasons).
If an incompatible protocol extension were defined, it would be
the responsibility of network management to ensure that
incompatible routers were not both present in the MANET; this case
is NOT RECOMMENDED.
o It would prevent the operation of end to end message o It would prevent the operation of end to end message
authentication using [RFC7182], or any similar mechanism. The use authentication using [RFC7182], or any similar mechanism. The use
of immutable (apart from hop count and/or hop limit) messages by a of immutable (apart from hop count and/or hop limit) messages by a
protocol is strongly RECOMMENDED for that reason. protocol is strongly RECOMMENDED for that reason.
5. Structure 5. Structure
This section concerns the properties of the format defined in
[RFC5444] itself, rather than the properties of protocols using it.
The elements defined in [RFC5444] have structures that are managed by The elements defined in [RFC5444] have structures that are managed by
a number of flags fields: a number of flags fields:
o Packet flags field (4 bits, 2 used) that manages the contents of o Packet flags field (4 bits, 2 used) that manages the contents of
the Packet Header. the Packet Header.
o Message flags field (4 bits, 4 used) that manages the contents of o Message flags field (4 bits, 4 used) that manages the contents of
the Message Header. the Message Header.
o Address Block flags field (8 bits, 4 used) that manages the o Address Block flags field (8 bits, 4 used) that manages the
skipping to change at page 16, line 44 skipping to change at page 18, line 32
o TLV flags field (8 bits, 5 used) that manages the contents of a o TLV flags field (8 bits, 5 used) that manages the contents of a
TLV. TLV.
Note that all of these flags are structural, they specify which Note that all of these flags are structural, they specify which
elements are present or absent, or field lengths, or whether a field elements are present or absent, or field lengths, or whether a field
has one or multiple values in it. has one or multiple values in it.
In the current version of [RFC5444], indicated by version number 0 in In the current version of [RFC5444], indicated by version number 0 in
the <version> field of the Packet Header, unused bits in these flags the <version> field of the Packet Header, unused bits in these flags
fields "are RESERVED and SHOULD each be cleared ('0') on transmission fields are stated as "are RESERVED and SHOULD each be cleared ('0')
and SHOULD be ignored on reception". on transmission and SHOULD be ignored on reception". For the
avoidance of any compatibility issues, for version number 0 this is
updated to "MUST each be cleared ('0') on transmission and MUST be
ignored on reception".
If a specification updating [RFC5444] introduces new flags in one of If a specification updating [RFC5444] introduces new flags in one of
the flags fields of a packet, message or Address Block, the following the flags fields of a packet, Address Block or TLV (there being no
rules MUST be followed: unused flags in the message flags field), the following rules MUST be
followed:
o The version number contained in the <version> field of the Packet o The version number contained in the <version> field of the Packet
Header MUST NOT be 0. Header MUST NOT be 0.
o The new flag(s) MUST indicate the structure of the corresponding o The new flag(s) MUST indicate the structure of the corresponding
packet, message, Address Block or TLV, and MUST NOT be used to packet, Address Block or TLV, and MUST NOT be used to indicate any
indicate any other semantics, such as message forwarding behavior. other semantics, such as message forwarding behavior.
An update that would be incompatible with the current specification An update that would be incompatible with the current specification
of [RFC5444] SHOULD NOT be created unless there is a pressing reason of [RFC5444] should not be created unless there is a pressing reason
for it that cannot be satisfied using the current specification for it that cannot be satisfied using the current specification
(e.g., by use of a suitable Message TLV). (e.g., by use of a suitable Message TLV).
During the development of [RFC5444], and since publication thereof, During the development of [RFC5444], and since publication thereof,
some proposals have been made to use these RESERVED flags to specify some proposals have been made to use these RESERVED flags to specify
behavior rather than structure, in particular message forwarding. behavior rather than structure, in particular message forwarding.
These proposals were, after due consideration, not accepted, for a These proposals were, after due consideration, not accepted, for a
number of reasons. These reasons include that message forwarding, in number of reasons. These reasons include that message forwarding, in
particular, is protocol-specific; for example [RFC7181] forwards particular, is protocol-specific; for example [RFC7181] forwards
messages using its MPR (Multi-Point Relay) mechanism, rather than a messages using its MPR (Multi-Point Relay) mechanism, rather than a
"blind" flooding mechanism. (The later addition of a 4 bit Message "blind" flooding mechanism. (These proposals were made during the
Address Length field later left no unused message flags bits, but development of [RFC5444] when there were still unused message flags.
other fields still have unused bits.) Later addition of a 4 bit Message Address Length field later left no
unused message flags, but other flags fields still have unused
flags.)
6. Message Efficiency 6. Message Efficiency
The ability to organize addresses into different, or the same, The ability to organize addresses into different, or the same,
Address Blocks, as well as to change the order of addresses within an Address Blocks, as well as to change the order of addresses within an
Address Block, and the flexibility of the TLV specification, enables Address Block, and the flexibility of the TLV specification, enables
avoiding unnecessary repetition of information, and consequently can avoiding unnecessary repetition of information, and consequently can
generate smaller messages. No algorithms for address organization or generate smaller messages. No algorithms for address organization or
compression or for TLV usage are given in [RFC5444], any algorithms compression or for TLV usage are given in [RFC5444], any algorithms
that leave the information content unchanged MAY be used when that leave the information content unchanged MAY be used when
generating a message. Note, however, that this does not apply when generating a message.
forwarding a message, a message that is (as strongly RECOMMENDED)
forwarded unchanged MUST have an identical octet representation,
other than that the owning protocol SHOULD increment and decrement,
respectively, the hop count and hop limit, if present.
6.1. Address Block Compression 6.1. Address Block Compression
Addresses in an Address Block can be compressed, and SHOULD be. [RFC5444] allows the addresses in an Address Block to be compressed.
A protocol generating a message SHOULD compress addresses as much as
it can.
Addresses in an Address Block consist of a Head, a Mid, and a Tail, Addresses in an Address Block consist of a Head, a Mid, and a Tail,
where all addresses in an Address Block have the same Head and Tail, where all addresses in an Address Block have the same Head and Tail,
but different Mids. Each has a length that is greater than or equal but different Mids. Each has a length that is greater than or equal
to zero, the sum of the lengths being the address length. (The Mid to zero, the sum of the lengths being the address length. (The Mid
length is deduced from this relationship.) Compression is possible length is deduced from this relationship.) Compression is possible
when the Head and/or the Tail have non-zero length. An additional when the Head and/or the Tail have non-zero length. An additional
compression is possible when the Tail consists of all zero-valued compression is possible when the Tail consists of all zero-valued
octets. Expected use cases are IPv4 and IPv6 addresses from within octets. Expected use cases are IPv4 and IPv6 addresses from within
the same prefix and which therefore have a common Head, IPv4 subnets the same prefix and which therefore have a common Head, IPv4 subnets
skipping to change at page 18, line 37 skipping to change at page 20, line 29
and the following TLV Block, and/or if additional TLVs are now and the following TLV Block, and/or if additional TLVs are now
required. required.
The order of addresses can be as simple as sorting the addresses, but The order of addresses can be as simple as sorting the addresses, but
if many addresses have the same TLV Types attached, it might be more if many addresses have the same TLV Types attached, it might be more
useful to put these addresses together, either within the same useful to put these addresses together, either within the same
Address Block as other addresses, or in a separate Address Block. A Address Block as other addresses, or in a separate Address Block. A
separate Address Block might also improve address compression, for separate Address Block might also improve address compression, for
example if more than one address form is used (such as from example if more than one address form is used (such as from
independent subnets). An example of the possible use of address independent subnets). An example of the possible use of address
ordering is a HELLO message from [RFC6130] which MAY be generated ordering is a HELLO message from [RFC6130] which could be generated
with local interface addresses first and neighbor addresses later. with local interface addresses first and neighbor addresses later.
These MAY be in separate Address Blocks. These could be in separate Address Blocks.
6.2. TLVs 6.2. TLVs
The main opportunities for creating more efficient messages when The main opportunities for creating more efficient messages when
considering TLVs are in Address Block TLVs, rather than Message TLVs. considering TLVs are in Address Block TLVs, rather than Message TLVs.
An Address Block TLV provides attributes for one address or a An Address Block TLV provides attributes for one address or a
contiguous (as stored in the Address Block) set of addresses (with a contiguous (as stored in the Address Block) set of addresses (with a
special case for when this is all addresses in an Address Block). special case for when this is all addresses in an Address Block).
When associated with more than one address, a TLV may be single value When associated with more than one address, a TLV may be single value
skipping to change at page 19, line 26 skipping to change at page 21, line 18
the LINK_METRIC TLV specified in OLSRv2 [RFC7181] is also added. the LINK_METRIC TLV specified in OLSRv2 [RFC7181] is also added.
o Allow the TLV to span over addresses that do not need the o Allow the TLV to span over addresses that do not need the
corresponding attribute, using a Value that indicates no corresponding attribute, using a Value that indicates no
information, see Section 6.3. information, see Section 6.3.
o Use more than one TLV. Note that this can be efficient when the o Use more than one TLV. Note that this can be efficient when the
TLVs thus become single value TLVs. In a typical case where a TLVs thus become single value TLVs. In a typical case where a
LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with
enough addresses, sorted appropriately, two single value TLVs can enough addresses, sorted appropriately, two single value TLVs can
be more efficient than one multivalue TLV. (When only one Value be more efficient than one multivalue TLV. If only one Value is
is involved, such as NHDP in a steady state with LINK_STATUS equal involved, such as NHDP in a steady state with LINK_STATUS equal to
to SYMMETRIC in all cases, one single value TLV SHOULD always be SYMMETRIC in all cases, then one single value TLV SHOULD always be
used.) used.
6.3. TLV Values 6.3. TLV Values
If, for example, an Address Block contains five addresses, the first If, for example, an Address Block contains five addresses, the first
two and the last two requiring Values assigned using a LINK_STATUS two and the last two requiring Values assigned using a LINK_STATUS
TLV, but the third does not, then this can be indicated using two TLV, but the third does not, then this can be indicated using two
TLVs. It is however more efficient to do this with one multivalue TLVs. It is however more efficient to do this with one multivalue
LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED. LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED.
In general, use of UNSPECIFIED Values allows use of fewer TLVs and In general, use of UNSPECIFIED Values allows use of fewer TLVs and
thus often an efficiency gain; however a long run of consecutive thus often an efficiency gain; however a long run of consecutive
UNSPECIFIED Values (more than the overhead of a TLV) may make more UNSPECIFIED Values (more than the overhead of a TLV) may make more
TLVs more efficient. TLVs more efficient.
This approach was specified in [RFC7188], and REQUIRED for protocols Some other TLVs may need a different approach. As noted in
that extend [RFC6130] and [RFC7181]. It is here RECOMMENDED that [RFC7188], but implicitly permissible before then, the LINK_METRIC
this approach (i.e., defining an UNSPECIFIED Value) is followed when TLV, defined in [RFC7181], has two octet Values whose first four bits
defining any Address Block TLV with discrete Values that may be used are flags indicating whether the metric applies in four cases; if
by a protocol using [RFC5444], and that a modified approach is used these are all zero then the metric does not apply in this case, which
where possible for other Address Block TLVs, as described below for is thus the equivalent of an UNSPECIFIED Value.
the LINK_METRIC TLV defined in [RFC7181].
It might be argued that this (provision of an UNSPECIFIED Value to [RFC7188] required that protocols that extend [RFC6130] and [RFC7181]
allow an Address Bloc TLV to cover unaffected addresses) is not allow unspecified values in TLVs where applicable. It is here
necessary in the example above, because the addresses can be RECOMMENDED that all protocols follow that advice, and use the same
reordered. However ordering addresses in such a way for all possible value (255). In particular, when defining any Address Block TLV with
TLVs is not, in general, possible. discrete Values that an UNSPECIFIED Value is defined, and that a
modified approach is used where possible for other Address Block
TLVs, for example as is done for a LINK_METRIC TLV (though not
necessarily using that exact approach).
As indicated, the LINK_STATUS TLV, and some other TLVs that take It might be argued that provision of an unspecified value (of any
single octet Values (per address), have a Value UNSPECIFIED defined, form) to allow an Address Block TLV to cover unaffected addresses is
as the Value 255, in [RFC7188]. A similar approach (and a similar not always necessary because addresses can be reordered to avoid
Value) is RECOMMENDED in any similar cases. Some other TLVs may need this. However ordering addresses to avoid this for all TLVs that may
a different approach. As noted in [RFC7188], but implicitly be used is not, in general, possible.
permissible before then, the LINK_METRIC TLV, defined in [RFC7181],
has two octet Values whose first four bits are flags indicating In addition, [RFC7188] RECOMMENDS that if a TLV Value (per address
whether the metric applies in four cases; if these are all zero then for an Address Block TLV) has a single-length that does not match the
the metric does not apply in this case, which is thus the equivalent defined length for that TLV Type, then the following rules are
of an UNSPECIFIED Value. adopted:
o If the received single-length is greater than the expected single-
length, then the excess octets MUST be ignored.
o If the received single-length is less than the expected single-
length, then the absent octets MUST be considered to have all bits
cleared (0).
6.4. Automation 6.4. Automation
There is scope for creating a protocol-independent optimizer for There is scope for creating a protocol-independent optimizer for
[RFC5444] messages that performs appropriate address re-organization [RFC5444] messages that performs appropriate address re-organization
(ordering and Address Block separation) and TLV changes (of number, (ordering and Address Block separation) and TLV changes (of number,
single- or multi- valuedness and use of UNSPECIFIED Values) to create single- or multi- valuedness and use of unspecified values) to create
more compact messages. The possible gain depends on the efficiency more compact messages. The possible gain depends on the efficiency
of the original message creation, and the specific details of the of the original message creation, and the specific details of the
message. Note that this process cannot be TLV Type independent, for message. Note that this process cannot be TLV Type independent, for
example a LINK_METRIC TLV has a more complicated Value structure than example a LINK_METRIC TLV has a more complicated Value structure than
a LINK_STATUS TLV does if using UNSPECIFIED Values. a LINK_STATUS TLV does if using UNSPECIFIED Values.
Such a protocol-independent optimizer MAY be used by the router Such a protocol-independent optimizer MAY be used by the router
generating a message, but MUST NOT be used on a message that is generating a message, but MUST NOT be used on a message that is
forwarded unchanged by a router. forwarded unchanged by a router.
7. Security Considerations 7. Security Considerations
This document does not specify a protocol, but provides rules and This document does not specify a protocol, but provides rules and
recommendations for how to design protocols using [RFC5444]. This recommendations for how to design protocols using [RFC5444], whose
document does not introduce any new security considerations; security considerations apply.
protocols designed according to these rules and recommendations are
subject to the security considerations detailed in [RFC5444]. In If the recommendation in Section 4.4.1 that messages are not modified
particular the applicability of the security framework for [RFC5444] (except for hop count and hop limit) when forwarded is followed, then
specified in [RFC7182] is unchanged. the security framework for [RFC5444] specified in [RFC7182] can be
used in full. If that recommendation is not followed, then the
Packet TLVs from [RFC7182] can be used, but the Message TLVs from
[RFC7182] cannot be used as intended.
In either case, a protocol using [RFC5444] MUST document whether it
is using [RFC7182] and if so, how.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. [This Section may be removed This document has no actions for IANA. [This Section may be removed
by the RFC Editor.] by the RFC Editor.]
9. Acknowledgments 9. Acknowledgments
The authors thank Cedric Adjih (INRIA) and Justin Dean (NRL) for The authors thank Cedric Adjih (INRIA) and Justin Dean (NRL) for
their contributions as authors of RFC 5444. their contributions as authors of RFC 5444.
skipping to change at page 22, line 16 skipping to change at page 24, line 16
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
(MANET) Protocols", RFC 5498, March 2009.
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", RFC 7182, April 2014.
[RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the MANET
Generalized Packet/Message Format", RFC 7631,
January 2015.
10.2. Informative References 10.2. Informative References
[G9903] "ITU-T G.9903: Narrow-band orthogonal frequency division [G9903] "ITU-T G.9903: Narrow-band orthogonal frequency division
multiplexing power line communication transceivers for G3- multiplexing power line communication transceivers for G3-
PLC networks", May 2013. PLC networks", May 2013.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
March 2009. March 2009.
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
(MANET) Protocols", RFC 5498, March 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
[RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621,
May 2012. May 2012.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol version 2",
RFC 7181, April 2014. RFC 7181, April 2014.
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", RFC 7182, April 2014.
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity
Protection for the Neighborhood Discovery Protocol (NHDP) Protection for the Neighborhood Discovery Protocol (NHDP)
and Optimized Link State Routing Protocol Version 2 and Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7183, April 2014. (OLSRv2)", RFC 7183, April 2014.
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing
Protocol version 2 (OLSRv2) and MANET Neighborhood Protocol version 2 (OLSRv2) and MANET Neighborhood
Discovery Protocol (NHDP) Extension TLVs", RFC 7183, Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
April 2014. April 2014.
[RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the MANET
Generalized Packet/Message Format", RFC 7631,
January 2015.
[RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for [RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for
the Optimized Link State Routing Protocol Version 2 the Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7722, December 2015. (OLSRv2)", RFC 7722, December 2015.
Authors' Addresses Authors' Addresses
Thomas Clausen Thomas Clausen
Ecole Polytechnique Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
 End of changes. 66 change blocks. 
211 lines changed or deleted 315 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/