draft-ietf-manet-rfc5444-usage-01.txt   draft-ietf-manet-rfc5444-usage-02.txt 
Network Working Group T. Clausen Network Working Group T. Clausen
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, 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: June 24, 2016 U. Herberg Expires: September 1, 2016 U. Herberg
H. Rogge H. Rogge
December 22, 2015 Fraunhofer FKIE
February 29, 2016
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-01 draft-ietf-manet-rfc5444-usage-02
Abstract Abstract
This document updates the generalized MANET packet/message format, This document updates the generalized MANET packet/message format,
specified in RFC 5444, by providing rules and recommendations for how specified in RFC 5444, by providing rules and recommendations for how
protocols can use that packet/message format. In particular, the protocols can use that packet/message format. In particular, the
mandatory rules prohibit a number of uses of RFC 5444 that have been mandatory rules prohibit a number of uses of RFC 5444 that have been
suggested in various proposals, and which would have led to suggested in various proposals, and which would have led to
interoperability problems, to the impediment of protocol extension interoperability problems, to the impediment of protocol extension
development, and to an inability to use generic RFC 5444 parsers. development, and to an inability to use generic RFC 5444 parsers.
skipping to change at page 1, line 40 skipping to change at page 1, line 42
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 June 24, 2016. This Internet-Draft will expire on September 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 26 skipping to change at page 2, line 28
1.3. Status of This Document . . . . . . . . . . . . . . . . . 5 1.3. Status of This Document . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
4. Information Transmission . . . . . . . . . . . . . . . . . . . 6 4. Information Transmission . . . . . . . . . . . . . . . . . . . 6
4.1. Where to Record Information . . . . . . . . . . . . . . . 6 4.1. Where to Record Information . . . . . . . . . . . . . . . 6
4.2. Packets and Messages . . . . . . . . . . . . . . . . . . . 7 4.2. Packets and Messages . . . . . . . . . . . . . . . . . . . 7
4.3. Messages, Addresses and Attributes . . . . . . . . . . . . 9 4.3. Messages, Addresses and Attributes . . . . . . . . . . . . 9
4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 9 4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 9
4.5. Information Representation . . . . . . . . . . . . . . . . 11 4.5. Information Representation . . . . . . . . . . . . . . . . 11
4.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 12 4.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 13
5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 14 6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Address Block Compression . . . . . . . . . . . . . . . . 14 6.1. Address Block Compression . . . . . . . . . . . . . . . . 14
6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 16 6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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. [RFC5498] mandates the use of this use by MANET routing protocols.
format by protocols operating over the manet IP protocol and port
numbers that were allocated following its request.
Following experiences with [RFC3626] which attempted, but did not [RFC5444] was designed following experiences with [RFC3626], which
quite succeed in, providing a packet/message format accommodating for attempted, but did not quite succeed in, providing a packet/message
diverse protocol extensions, [RFC5444] was designed by the MANET format accommodating for diverse protocol extensions. [RFC5444] was
working group as a common building block for use by both proactive designed as a common building block for use by both proactive and
and reactive MANET routing protocols. reactive MANET routing protocols.
[RFC5498] mandates the use of this packet/message format, and of the
packet multiplexing process described in an Appendix to [RFC5444], by
protocols operating over the manet IP protocol and port numbers that
were allocated following [RFC5498].
1.1. History and Purpose 1.1. History and Purpose
Since the publication of [RFC5444] in 2009, several RFCs have been Since the publication of [RFC5444] in 2009, several RFCs have been
published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181], published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181],
[RFC7182], [RFC7183], [RFC7188], and [RFC7631], that use the format [RFC7182], [RFC7183], [RFC7188], and [RFC7631], that use the format
of [RFC5444]. The ITU-T recommendation [G9903] also uses the format of [RFC5444]. The ITU-T recommendation [G9903] also uses the format
of [RFC5444] for encoding some of its control signals. In developing of [RFC5444] for encoding some of its control signals. In developing
these specifications, experience with the use of [RFC5444] has been these specifications, experience with the use of [RFC5444] has been
acquired, specifically with respect to how to write specifications acquired, specifically with respect to how to write specifications
skipping to change at page 3, line 51 skipping to change at page 4, line 5
[RFC5444]. [RFC5444].
1.2. RFC 5444 Features 1.2. RFC 5444 Features
Among the characteristics, and design criteria, of the packet/message Among the characteristics, and design criteria, of the packet/message
format of [RFC5444] are: format of [RFC5444] are:
o It is designed for carrying MANET routing protocol control o It is designed for carrying MANET routing protocol control
signals. signals.
o It defines a packet as a Packet Header with a set of Packet TLVs, o It defines a packet as a Packet Header with a set of Packet TLVs
followed by a set of messages. Each message has a well-defined (Type-Length-Value structures), followed by a set of messages.
structure consisting of a Message Header (designed for making Each message has a well-defined structure consisting of a Message
processing and forwarding decisions) followed by a set of Message Header (designed for making processing and forwarding decisions)
TLVs (Type-Length-Value structures), and a set of (address, type, followed by a set of Message TLVs, and a set of (address, type,
value) associations using Address Blocks and their Address Block value) associations using Address Blocks and their Address Block
TLVs. The [RFC5444] packet/message format then enables the use of TLVs. The [RFC5444] packet/message format then enables the use of
simple and generic parsing logic for packets, Message Headers, and simple and generic parsing logic for Packet Headers, Message
message content. Headers, and message content.
A packet may include messages from different protocols, such as A packet may include messages from different protocols, such as
[RFC6130] and [RFC7181], in a single transmission. This was [RFC6130] and [RFC7181], in a single transmission. This was
observed in [RFC3626] to be beneficial, especially in wireless observed in [RFC3626] to be beneficial, especially in wireless
networks where media contention may be significant. [RFC5444] networks where media contention may be significant. [RFC5444]
defines a multiplexing process to achieve this that is mandated by defines a multiplexing process to achieve this that is mandated by
[RFC5498] for use on the manet IP port and UDP port. This makes [RFC5498] for use on the manet IP port and UDP port. This makes
the contents of the Packet Header, which may also contain Packet the contents of the Packet Header, which may also contain Packet
TLVs, and the transmission of packets over UDP or directly over TLVs, and the transmission of packets over UDP or directly over
IP, the responsibility of this multiplexing process. IP, the responsibility of this multiplexing process.
skipping to change at page 4, line 36 skipping to change at page 4, line 39
the Packet Sequence Number can be used to count transmission the Packet Sequence Number can be used to count transmission
successes across that link). Packets are not retransmitted, a successes across that link). Packets are not retransmitted, a
packet transmission following a successful packet reception may packet transmission following a successful packet reception may
include all, some, or none of the received messages, plus possibly include all, some, or none of the received messages, plus possibly
additional messages received in separate packets or generated at additional messages received in separate packets or generated at
that router. Messages may thus travel more than one hop, and are that router. Messages may thus travel more than one hop, and are
designed to carry end-to-end protocol signals. designed to carry end-to-end protocol signals.
o It supports "internal extensibility" using TLVs; an extension can o It supports "internal extensibility" using TLVs; an extension can
add information to an existing message without that information add information to an existing message without that information
rendering the message un-parseable by a router that does not rendering the message unparseable or unusable by a router that
support the extension. An extension is typically of the protocol does not support the extension. An extension is typically of the
that created the message to be extended, for example [RFC7181] protocol that created the message to be extended, for example
adds information to the HELLO messages created by [RFC6130]. [RFC7181] adds information to the HELLO messages created by
However an extension may also be independent of the protocol, for [RFC6130]. However an extension may also be independent of the
example [RFC7182] can add ICV (Integrity Check Value) and protocol, for example [RFC7182] can add ICV (Integrity Check
timestamp information to any message (or to a packet, thus Value) and timestamp information to any message (or to a packet,
extending the [RFC5444] multiplexing process). thus extending the [RFC5444] multiplexing process).
Information can be added to the message as a whole, such as the Information can be added to the message as a whole, such as the
[RFC7182] integrity information, or may be associated with [RFC7182] integrity information, or may be associated with
specific addresses in the message, such as the MPR selection and specific addresses in the message, such as the MPR selection and
link metric information added to HELLO messages by [RFC7181]. An link metric information added to HELLO messages by [RFC7181]. An
extension may also add addresses to a message. extension may also add addresses to a message.
o It uses address aggregation into compact Address Blocks by o It uses address aggregation into compact Address Blocks by
exploiting commonalities between addresses. In many deployments, exploiting commonalities between addresses. In many deployments,
addresses (IPv4 and IPv6) used on interfaces share a common prefix addresses (IPv4 and IPv6) used on interfaces share a common prefix
skipping to change at page 6, line 37 skipping to change at page 6, line 37
The first case (a Packet TLV) can only be used when the information The first case (a Packet TLV) can only be used when the information
is to be carried one hop. It SHOULD only be used either where the 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 the single if the information is of expected wider application than the 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]. While this is not the most common case, protocols SHOULD
be designed to enable this to be possible, and most rules in this be designed to enable this to be possible, and most rules in this
document are to help facilitate that. An extension to [RFC5444], document are to help facilitate that. An extension to [RFC5444],
such as [RFC7182], is considered to be an extension to all protocols such as [RFC7182], is considered to be an extension to all protocols
in this regard. in this regard.
The third case is the normal case for a new protocol. Protocols MUST The third case is the normal case for a new protocol. Protocols MUST
be conservative in the number of new message types that they require, be conservative in the number of new message types that they require,
as the total available number of allocatable message types is only as the total available number of allocatable message types is only
224. Protocol design SHOULD consider whether different functions can 224. Protocol design SHOULD consider whether different functions can
be implemented by differences in TLVs carried in the same Message be implemented by differences in TLVs carried in the same Message
Type, rather than using multiple Message Types. If a protocol's Type, rather than using multiple Message Types. If a protocol's
needs can be covered by use of the second case, then this SHOULD be needs can be covered by use of the second case, then this SHOULD be
done. done.
TLV space, although greater than message space, SHOULD also be used TLV space, although greater than message space, SHOULD also be used
efficiently. The extended type of a TLV occupies two octets, thus efficiently. The extended type of a TLV occupies two octets, thus
there are many more available TLVs. However, in some cases there are many more available TLVs. However, in some cases
(currently LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from (currently LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from
[RFC7182] in the global TLV space) a full set of 256 TLVs is defined [RFC7182] in the global TLV space) a full set of 256 TLVs is defined
(but not necessarily allocated). Each message has a block of message (but not necessarily allocated). Each message also has a block of
specific TLV Types (128 to 233, each with 256 type extensions), these message specific TLV Types (128 to 233, each with 256 type
SHOULD be used in preference to the common TLV Types (0 to 127, each extensions), these SHOULD be used in preference to the common TLV
with 256 type extensions) when a TLV is message-specific. Types (0 to 127, each with 256 type extensions) when a TLV is
message-specific.
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 type, A message MUST be recognized by the combination of its type,
Originator Address and Message Sequence Number. This allows each Originator Address and Message Sequence Number. This allows each
protocol to manage its own Message Sequence Numbers, and also allows protocol to manage its own Message Sequence Numbers, and also allows
for the possibility that different Message Types may have greatly for the possibility that different Message Types may have greatly
skipping to change at page 8, line 44 skipping to change at page 8, line 44
multiplexing process SHOULD respect this request if possible. A multiplexing process SHOULD respect this request if possible. A
protocol MAY also request that a Packet Sequence Number and/or protocol MAY also request that a Packet Sequence Number and/or
specified Packet TLVs are included, such requests SHOULD also be specified Packet TLVs are included, such requests SHOULD also be
respected if possible. respected if possible.
o The multiplexing process SHOULD combine messages from multiple o The multiplexing process SHOULD combine messages from multiple
protocols that are sent on the same interface in a packet, protocols that are sent on the same interface in a packet,
provided that in so doing the multiplexing process does not cause provided that in so doing the multiplexing process does not cause
an IP packet to exceed the current MTU (Maximum Transmission an IP packet to exceed the current MTU (Maximum Transmission
Unit). (Note that the multiplexing process cannot fragment Unit). (Note that the multiplexing process cannot fragment
messages, creating suitable sized messages is the responsibility messages; creating suitable sized messages is the responsibility
of the protocol.) of the protocol.)
o If requested by a protocol the multiplexer SHOULD, and otherwise o If requested by a protocol, the multiplexer SHOULD, and otherwise
MAY, include a Packet Sequence Number in the packet. Note that, MAY, include a Packet Sequence Number in the packet. Note that,
as per the errata to [RFC5444], this Packet Sequence Number MUST as per the errata to [RFC5444], this Packet Sequence Number MUST
be specific to the interface on which the packet is sent. be specific to the interface on which the packet is sent.
o An extension to the multiplexing process MAY add TLVs to the o An extension to the multiplexing process MAY add TLVs to the
packet and/or the messages (for example as by [RFC7182]). packet and/or the messages (for example as by [RFC7182]).
4.3. Messages, Addresses and Attributes 4.3. 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
skipping to change at page 9, line 29 skipping to change at page 9, line 29
extended type, a length, and a value (of that length). extended 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 extended type MAY be (and this is RECOMMENDED whenever A TLV extended type MAY be (and this is RECOMMENDED whenever
possible) defined so that there may only be one TLV of that extended possible) defined so that there may only be one TLV of that extended
type associated with the message (Message TLV) or any value of any type associated with the packet (Packet TLV), message (Message TLV),
address (Address Block TLV). Note that an address may appear more or any value of any address (Address Block TLV). Note that an
than once in a message, but the restriction on associating TLVs with address may appear more than once in a message, but the restriction
addresses covers all copies of that address. It is RECOMMENDED that on associating TLVs with addresses covers all copies of that address.
addresses are not repeated in a message. It is RECOMMENDED that addresses are not repeated in a message.
4.4. Addresses Require Attributes 4.4. 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.
This specification, however, requires that those methods of carrying This specification, however, requires that those methods of carrying
information MUST NOT be used for any protocol using [RFC5444]. information MUST NOT be used for any protocol using [RFC5444].
Information about the meaning of an address MUST only be carried Information about the meaning of an address MUST only be carried
using Address Block TLVs. using Address Block TLVs.
In addition, rules for the extensibility of OLSRv2 and NHDP are In addition, rules for the extensibility of OLSRv2 and NHDP are
described in [RFC7188]. This specification extends their described in [RFC7188]. This specification extends their
applicability to other uses of [RFC5444]. applicability to other uses of [RFC5444].
These rules are:
o A protocol MUST NOT assign any meaning to the presence or absence
of an address, to the ordering of addresses in an Address Block,
or to the division of addresses among Address Blocks.
o A protocol MUST NOT reject a message based on the inclusion of a
TLV of an unrecognized type. The protocol MUST ignore any such
TLVs when processing the message. The protocol MUST NOT remove or
change any such TLVs if the message is to be forwarded unchanged.
o A protocol MUST NOT reject a message based on the inclusion of an
unrecognized Value in a TLV of a recognized type. The protocol
MUST ignore any such Values when processing the message, but MUST
NOT ignore recognized Values in the such a TLV. The protocol MUST
NOT remove or change any such TLVs if the message is to be
forwarded unchanged.
o Similar restrictions to the two preceding points apply to the
packet multiplexing process, which also MUST NOT reject a packet
based on an unrecognized message; although it will reject any such
messages, it MUST deliver any other messages in the packet to
their owning protocols.
The following points indicate the reasons for these rules, based on The following points indicate the reasons for these rules, based on
considerations of extensibility and efficiency. considerations of extensibility and efficiency.
A protocol MUST NOT assign any meaning to the presence, or absence, Assigning a meaning to the presence, absence or location, of an
of an address, as this would prevent the addition of addresses with address would reduce the extensibility of the protocol, prevent the
other meanings. For example consider NHDP's HELLO messages approach to information representation described in Section 4.5, and
[RFC6130]. The basic function of a HELLO message is to indicate that reduce the options available for message optimization described in
an address is of a neighbor, using the LINK_STATUS and OTHER_NEIGHB Section 6.
TLVs. An extension to NHDP might decide to use the HELLO message to
report that, for example, an address is one that could be used for a For example, consider NHDP's HELLO messages [RFC6130]. The basic
specialized purpose, but not for normal NHDP-based purposes. Such an function of a HELLO message is to indicate that an address is of a
example already exists (but within the basic specification, rather neighbor, using the LINK_STATUS and OTHER_NEIGHB TLVs. An extension
than as an extension) in the use of LOST Values in the LINK_STATUS to NHDP might decide to use the HELLO message to report that, for
and OTHER_NEIGHB TLVs to report that an address is of a router known example, an address is one that could be used for a specialized
not to be a neighbor. A future example might be to list an address purpose, but not for normal NHDP-based purposes. Such an example
to be added to a "blacklist" of addresses not to be used. This would already exists (but within the basic specification, rather than as an
be indicated by a new TLV (or a new Value of an existing TLV, see extension) in the use of LOST Values in the LINK_STATUS and
OTHER_NEIGHB TLVs to report that an address is of a router known not
to be a neighbor. A future example might be to list an address to be
added to a "blacklist" of addresses not to be used. This would be
indicated by a new TLV (or a new Value of an existing TLV, see
below). An unmodified extension to NHDP would ignore such addresses, below). An unmodified extension to NHDP would ignore such addresses,
as required, as it does not support that specialized purpose. If as required, as it does not support that specialized purpose. If
NHDP had been designed so that just the presence of an address NHDP had been designed so that just the presence of an address
indicated a neighbor, that extension would not have been possible. indicated a neighbor, that extension would not have been possible.
This example can be taken further. NHDP must also not reject a HELLO Rejecting a message because it contains an unrecognized TLV type, or
message because it contains an unrecognized TLV. This also applies an unrecognized TLV Value, reduces the extensibility of the protocol.
to unrecognized TLV Values, where a TLV supports only a limited set
of Values. For example, the blacklisting described in the previous
paragraph could be signaled not with a new TLV, but with a new Value
of a LINK_STATUS or OTHER_NEIGHB TLV (requiring an IANA allocation as
described in [RFC7188]), as is already done in the LOST case.
Information may also be added to addresses recognized by the base For example, OLSRv2 [RFC7181] is, among other things, an extension to
protocol. For example OLSRv2 [RFC7181] is, among other things, an NHDP. It adds information to addresses in an NHDP HELLO message
extension to NHDP. It adds information to addresses in an NHDP HELLO using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP, for
message using a LINK_METRIC TLV. A non-OLSRv2 implementation of example to support Simplified Multicast Flooding (SMF) [RFC6621],
NHDP, for example to support Simplified Multicast Flooding (SMF) must still process the HELLO message, ignoring the LINK_METRIC TLVs.
[RFC6621], must still process the HELLO message, ignoring the
LINK_METRIC TLVs.
This does not, however, mean that added information is completely Also, the blacklisting described in the example above could be
ignored for purposes of the base protocol. Suppose that a faulty signaled not with a new TLV, but with a new Value of a LINK_STATUS or
implementation of OLSRv2 (including NHDP) creates a HELLO message OTHER_NEIGHB TLV (requiring an IANA allocation as described in
that assigns two different values of the same link metric to an [RFC7188]), as is already done in the LOST case.
address, something that is not permitted by [RFC7181]. A receiving
OLSRv2-aware implementation of NHDP MUST reject such a message, even
though a receiving OLSRv2-unaware implementation of NHDP will process
it. This is because the OLSRv2-aware implementation has access to
additional information, that the HELLO message is definitely invalid,
and the message is best ignored, as it is unknown what other errors
it may contain.
The restrictions on the use of address ordering and an address The creation of Multi-Topology OLSRv2 (MT-OLSRv2) [RFC7722], as an
presence or absence in given Address Blocks for carrying information extension to OLSRv2 that can interoperate with unextended instances
are for two reasons. First, use of those prevents the approach to of OLSRv2, would not have been possible without these restrictions,
information representation described in Section 4.5. Second, it which were applied to NHDP and OLSRv2 by [RFC7181].
reduces the options available for message optimization described in
Section 6. These restrictions do not, however, mean that added information is
completely ignored for purposes of the base protocol. Suppose that a
faulty implementation of OLSRv2 (including NHDP) creates a HELLO
message that assigns two different values of the same link metric to
an address, something that is not permitted by [RFC7181]. A
receiving OLSRv2-aware implementation of NHDP MUST reject such a
message, even though a receiving OLSRv2-unaware implementation of
NHDP will process it. This is because the OLSRv2-aware
implementation has access to additional information, that the HELLO
message is definitely invalid, and the message is best ignored, as it
is unknown what other errors it may contain.
4.5. Information Representation 4.5. Information Representation
A message (excluding the Message Header) can thus be represented by A message (excluding the Message Header) can thus be represented by
two, possibly multivalued, maps: two, possibly multivalued, maps:
o Message: (extended type) -> (length, value) o Message: (extended type) -> (length, value)
o Address: (address, extended type) -> (length, value) o Address: (address, extended type) -> (length, value)
skipping to change at page 12, line 20 skipping to change at page 12, line 44
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
RFC [RFC7181], except where those requirements are ones that MUST be [RFC7188], except where those requirements are ones that MUST be
followed as required by this specification (or when extending followed as required by this specification (or when extending
[RFC6130] or [RFC7181], when these MUST also be followed). [RFC6130] or [RFC7181], when these MUST also be followed).
4.7. Message Integrity 4.7. 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 fail to forward a message (by whatever
means of message forwarding are appropriate to that protocol) due to means of message forwarding are appropriate to that protocol) due to
the presence of such TLVs or TLV Values, and MUST NOT remove such the presence of such TLVs or TLV Values, and MUST NOT remove such
TLVs or TLV Values. Such behavior would have the consequences that: TLVs or TLV Values. Such behavior would have the consequences that:
skipping to change at page 14, line 30 skipping to change at page 15, line 8
Addresses in an Address Block can be compressed, and SHOULD be. Addresses in an Address Block can be compressed, and SHOULD be.
Compression of addresses in an Address Block considers addresses to Compression of addresses in an Address Block considers addresses to
consist of a Head, a Mid, and a Tail, where all addresses in an consist of a Head, a Mid, and a Tail, where all addresses in an
Address Block have the same Head and Tail, but different Mids. An Address Block have the same Head and Tail, but different Mids. An
additional compression is possible when the Tail consists of all additional compression is possible when the Tail consists of all
zero-valued octets. Expected use cases are IPv4 and IPv6 addresses zero-valued octets. Expected use cases are IPv4 and IPv6 addresses
from within the same prefix and which therefore have a common Head, from within the same prefix and which therefore have a common Head,
IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with
a common Tail representing an interface identifier as well as a a common Tail representing an interface identifier as well as having
possible common Head. Note that when, for example, IPv4 addresses a possible common Head. Note that when, for example, IPv4 addresses
have a common Head, their Tail will usually be empty. For example have a common Head, their Tail will usually be empty. For example
192.0.2.1 and 192.0.2.2 would, for greatest efficiency, have a 3 192.0.2.1 and 192.0.2.2 would, for greatest efficiency, have a 3
octet Head, a 1 octet Mid, and a 0 octet Tail. octet Head, a 1 octet Mid, and a 0 octet Tail.
Putting addresses into a message efficiently also has to include: Putting addresses into a message efficiently also has to include:
o The split of the addresses into Address Blocks. o The split of the addresses into Address Blocks.
o The order of the addresses within the Address Blocks. o The order of the addresses within the Address Blocks.
skipping to change at page 16, line 12 skipping to change at page 16, line 37
to SYMMETRIC in all cases, one single value TLV SHOULD always be to SYMMETRIC in all cases, 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
thus often an efficiency gain; however a long run of consecutive
UNSPECIFIED Values (more than the overhead of a TLV) may make more
TLVs more efficient.
This approach was specified in [RFC7188], and required for protocols This approach was specified in [RFC7188], and required for protocols
that extend [RFC6130] and [RFC7181]. It is here RECOMMENDED that that extend [RFC6130] and [RFC7181]. It is here RECOMMENDED that
this approach is followed when defining any Address Block TLV that this approach is followed when defining any Address Block TLV that
may be used by a protocol using [RFC5444]. may be used by a protocol using [RFC5444].
It might be argued that this is not necessary in the example above, It might be argued that this is not necessary in the example above,
because the addresses can be reordered. However ordering addresses because the addresses can be reordered. However ordering addresses
in such a way for all possible TLVs is not, in general, possible. in such a way for all possible TLVs is not, in general, possible.
As indicated, the LINK_STATUS TLV, and some other TLVs that take As indicated, the LINK_STATUS TLV, and some other TLVs that take
skipping to change at page 17, line 11 skipping to change at page 17, line 40
subject to the security considerations detailed in [RFC5444]. In subject to the security considerations detailed in [RFC5444]. In
particular the applicability of the security framework for [RFC5444] particular the applicability of the security framework for [RFC5444]
specified in [RFC7182] is unchanged. specified in [RFC7182] is unchanged.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Acknowledgments 9. Acknowledgments
TBD. The authors thank Cedric Adjih (INRIA) and Justin Dean (NRL) for
their contributions as authors of RFC 5444.
10. References 10. References
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,
skipping to change at page 18, line 23 skipping to change at page 19, line 12
[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 7183,
April 2014. April 2014.
[RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the MANET [RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the MANET
Generalized Packet/Message Format", RFC 7631, Generalized Packet/Message Format", RFC 7631,
January 2015. January 2015.
[RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for
the Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7722, December 2015.
Authors' Addresses Authors' Addresses
Thomas Clausen Thomas Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
Phone: +33-6-6058-9349 Phone: +33-6-6058-9349
Email: T.Clausen@computer.org Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org URI: http://www.thomasclausen.org
Christopher Dearlove Christopher Dearlove
BAE Systems Applied Intelligence Laboratories BAE Systems Applied Intelligence Laboratories
West Hanningfield Road West Hanningfield Road
Great Baddow, Chelmsford Great Baddow, Chelmsford
United Kingdom United Kingdom
Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com
Ulrich Herberg Ulrich Herberg
Email: ulrich@herberg.name Email: ulrich@herberg.name
URI: http://www.herberg.name URI: http://www.herberg.name
Henning Rogge Henning Rogge
Fraunhofer FKIE
Fraunhofer Strasse 20
53343 Wachtberg
Germany
Email: henning.rogge@fkie.fraunhofer.de Email: henning.rogge@fkie.fraunhofer.de
 End of changes. 34 change blocks. 
100 lines changed or deleted 143 lines changed or added

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