draft-ietf-manet-rfc5444-usage-03.txt   draft-ietf-manet-rfc5444-usage-04.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: October 7, 2016 U. Herberg Expires: November 5, 2016 U. Herberg
H. Rogge H. Rogge
Fraunhofer FKIE Fraunhofer FKIE
April 5, 2016 May 4, 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-03 draft-ietf-manet-rfc5444-usage-04
Abstract Abstract
This document updates the generalized MANET packet/message format, RFC 5444 specifies a generalized MANET packet/message format and
specified in RFC 5444, by providing rules and recommendations for how describes an intended use to multiplex MANET routing protocol
protocols can use that packet/message format. In particular, the messages that is mandated for use by RFC 5498. This document updates
mandatory rules prohibit a number of uses of RFC 5444 that have been RFC 5444 by providing rules and recommendations for how the
suggested in various proposals, and which would have led to multiplexer operates and how protocols can use the packet/message
interoperability problems, to the impediment of protocol extension format. In particular, the mandatory rules prohibit a number of uses
development, and to an inability to use generic RFC 5444 parsers. of RFC 5444 that have been suggested in various proposals, and which
would have led to interoperability problems, to the impediment of
protocol extension development, and to an inability to use optional
generic RFC 5444 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 October 7, 2016. This Internet-Draft will expire on November 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 19 skipping to change at page 2, line 22
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 . . . . . . . . . . . 5 1.2.2. Multiplexing and Demultiplexing . . . . . . . . . . . 6
1.3. Status of This Document . . . . . . . . . . . . . . . . . 6 1.3. Status of This Document . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
4. Information Transmission . . . . . . . . . . . . . . . . . . . 7 4. Information Transmission . . . . . . . . . . . . . . . . . . . 7
4.1. Where to Record Information . . . . . . . . . . . . . . . 7 4.1. Where to Record Information . . . . . . . . . . . . . . . 7
4.2. Packets and Messages . . . . . . . . . . . . . . . . . . . 9 4.2. Message Multiplexing and Packets . . . . . . . . . . . . . 9
4.3. Messages, Addresses and Attributes . . . . . . . . . . . . 10 4.3. Messages, Addresses and Attributes . . . . . . . . . . . . 11
4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 11 4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 12
4.5. Information Representation . . . . . . . . . . . . . . . . 13 4.5. Information Representation . . . . . . . . . . . . . . . . 14
4.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 14 4.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 15
5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 16 6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Address Block Compression . . . . . . . . . . . . . . . . 16 6.1. Address Block Compression . . . . . . . . . . . . . . . . 17
6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 19 6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 3, line 25 skipping to change at page 3, line 25
[RFC5498] mandates the use of this packet/message format, and of the [RFC5498] mandates the use of this packet/message format, and of the
packet multiplexing process described in an Appendix to [RFC5444], by packet multiplexing process described in an Appendix to [RFC5444], by
protocols operating over the manet IP protocol and port numbers that protocols operating over the manet IP protocol and port numbers that
were allocated following [RFC5498]. 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], [RFC7631], and [RFC7722], that use
of [RFC5444]. The ITU-T recommendation [G9903] also uses the format the format of [RFC5444]. The ITU-T recommendation [G9903] also uses
of [RFC5444] for encoding some of its control signals. In developing the format of [RFC5444] for encoding some of its control signals. In
these specifications, experience with the use of [RFC5444] has been developing these specifications, experience with the use of [RFC5444]
acquired, specifically with respect to how to write specifications has been acquired, specifically with respect to how to write
using [RFC5444] so as to ensure "forward compatibility" of a protocol specifications using [RFC5444] so as to ensure "forward
with future extensions, to enable the creation of efficient messages, compatibility" of a protocol with future extensions, to enable the
and to enable the use of an efficient and generic parser for all creation of efficient messages, and to enable the use of an efficient
protocols using [RFC5444]. and generic parser for all protocols using [RFC5444].
During the same time period, other suggestions have been made to use During the same time period, other suggestions have been made to use
[RFC5444] in a manner that would inhibit the development of [RFC5444] in a manner that would inhibit the development of
interoperable protocol extensions, that would potentially lead to interoperable protocol extensions, that would potentially lead to
inefficiencies, or that would lead to incompatibilities with generic inefficiencies, or that would lead to incompatibilities with generic
parsers for [RFC5444]. While these uses were not all explicitly parsers for [RFC5444]. While these uses were not all explicitly
prohibited by [RFC5444], they should be strongly discouraged. This prohibited by [RFC5444], they should be strongly discouraged. This
document is intended to prohibit such uses, to present experiences document is intended to prohibit such uses, to present experiences
from designing protocols using [RFC5444], and to provide these as from designing protocols using [RFC5444], and to provide these as
guidelines (with their rationale) for future protocol designs using guidelines (with their rationale) for future protocol designs using
[RFC5444]. [RFC5444].
1.2. RFC 5444 Features 1.2. RFC 5444 Features
[RFC5444] performs two main functions: [RFC5444] performs two main functions:
o It defines a packet/message format for use by MANET routing o It defines a packet/message format for use by MANET routing
protocols. Although not required by [RFC5444], it is natural to protocols. As far as [RFC5444] is concerned, it is up to each
implement this using protocol-independent packet/message creation protocol that uses it to implement the required message parsing
and parsing processes. and formation. It is natural, especially when implementing more
than one such protocol, to implement these processes using
protocol-independent packet/message creation and parsing
procedures, however this is not required by [RFC5444]. Some
comments in this document may be particularly applicable to such a
case, but all that is required is that the messages passed to and
from protocols are correctly formatted, and that packets
containing those messages are correctly formatted as described in
the following point.
o It specifies, in its Appendix A combined with the intended usage o It specifies, in its Appendix A combined with the intended usage
in its Appendix B, a multiplexing and demultiplexing process in its Appendix B, a multiplexing and demultiplexing process
whereby an entity which may be referred to as the "RFC 5444 whereby an entity which may be referred to as the "RFC 5444
multiplexer" (in this document, simply as the multiplexer, or multiplexer" (in this document simply as the multiplexer, or the
demultiplexer when performing that function) manages packets that demultiplexer when performing that function) manages packets that
travel a single (logical) hop, and which contain messages that are travel a single (logical) hop, and which contain messages that are
owned by individual protocols. A packet may contain messages from owned by individual protocols. A packet may contain messages from
more than one protocol. This process, and its usage, is mandated more than one protocol. This process, and its usage, is mandated
for use on the "manet" UDP port and IP protocol (alternative means for use on the manet UDP port and IP protocol (alternative means
for the transport of packets) by [RFC5498]. for the transport of packets) by [RFC5498]. The multiplexer is
responsible for creating packets and for parsing packet headers,
extracting messages, and passing them to the appropriate protocol
according to their type (the first octet in the message).
1.2.1. Packet/Message Format 1.2.1. Packet/Message Format
Among the characteristics and design objectives of the packet/message Among the characteristics and design objectives 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
skipping to change at page 4, line 41 skipping to change at page 5, line 6
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 Packet Headers, Message simple and generic parsing logic for Packet Headers, Message
Headers, and 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. networks where media contention may be significant.
o Its packets are designed to travel between two neighboring o Its packets are designed to travel between two neighboring
interfaces, which will result in a single decrement/increment of interfaces, which will result in a single decrement of the IPv4
the IPv4 TTL or IPv6 hop limit. The Packet Header and any Packet TTL or IPv6 hop limit. The Packet Header and any Packet TLVs may
TLVs may thus convey information relevant to that link (for thus convey information relevant to that link (for example, the
example, the Packet Sequence Number can be used to count Packet Sequence Number can be used to count transmission successes
transmission successes across that link). Packets are designed to across that link). Packets are designed to be constructed for a
be constructed for a single hop transmission; a packet single hop transmission; a packet transmission following a
transmission following a successful packet reception is by design successful packet reception is by design of a new packet that may
of a new packet that may include all, some, or none of the include all, some, or none of the received messages, plus possibly
received messages, plus possibly additional messages either additional messages either received in separate packets, or
received in separate packets, or generated locally at that router. generated locally at that router. Messages may thus travel more
Messages may thus travel more than one hop, and are designed to than one hop, and are designed to carry end-to-end protocol
carry end-to-end protocol signals. 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 unparseable or unusable by a router that rendering the message unparseable or unusable by a router that
does not support the extension. An extension is typically of the does not support the extension. An extension is typically of the
protocol that created the message to be extended, for example protocol that created the message to be extended, for example
[RFC7181] adds information to the HELLO messages created by [RFC7181] adds information to the HELLO messages created by
[RFC6130]. However an extension may also be independent of the [RFC6130]. However an extension may also be independent of the
protocol, for example [RFC7182] can add ICV (Integrity Check protocol, for example [RFC7182] can add ICV (Integrity Check
Value) and timestamp information to any message (or to a packet, Value) and timestamp information to any message (or to a packet,
skipping to change at page 6, line 7 skipping to change at page 6, line 18
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
hop, and to send packets using the "manet" UDP port or IP protocol hop, and to send packets using the manet UDP port or IP protocol
defined in [RFC5498]. defined in [RFC5498].
o Extract messages from received packets, and pass them to their o Extract messages from received packets, and pass them to their
owning protocols. owning protocols.
The multiplexer's relationship is with the protocols that own the
corresponding Message Types. Where those protocols have their own
relationships, for example as extensions, this is the responsibility
of the protocols. For example OLSRv2 [RFC7181] extends the HELLO
messages created by NHDP [RFC6130]. However the multiplexer will
deliver HELLO messages to NHDP and will expect to receive HELLO
messages from NHDP, the relationship between NHDP and OLSRv2 is
between those two protocols.
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.2.
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
skipping to change at page 6, line 41 skipping to change at page 7, line 14
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This document uses the terminology and notation defined in [RFC5444], This document uses the terminology and notation defined in [RFC5444],
in particular the terms "packet", "Packet Header", "message", in particular the terms "packet", "Packet Header", "message",
"Message Header", "address", "Address Block", "TLV" and "TLV Block" "Message Header", "address", "Address Block", "TLV" and "TLV Block"
are to be interpreted as described therein. are to be interpreted as described therein.
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Full Type (of TLV) - As per [RFC5444], the 16-bit combination of the
TLV Type and Type Extension is given the symbolic name <tlv-
fulltype>, but is not assigned the term "Full Type", which is
however assigned by this document as standard terminology.
Owning Protocol - As per [RFC5444], for each Message Type, a Owning Protocol - As per [RFC5444], for each Message Type, a
protocol -- unless specified otherwise, the one making the IANA protocol -- unless specified otherwise, the one making the IANA
reservation for that Message Type -- is designated as the "owning reservation for that Message Type -- is designated as the "owning
protocol" of that Message Type. The (de)multiplexer inspects the protocol" of that Message Type. The (de)multiplexer inspects the
Message Type of each received message, and delivers each message Message Type of each received message, and delivers each message
to its corresponding "owning protocol". to its corresponding "owning protocol".
3. Applicability Statement 3. Applicability Statement
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 which 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 number, defined therein. Thus, the constraints in protocol and port, defined therein. Thus, the constraints in this
this document apply to all protocols running over the manet protocol document apply to all protocols running over the manet protocol and
and port number. port.
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 7, line 46 skipping to change at page 8, line 23
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]. 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 some of the rules in
document are to help facilitate that. An extension to [RFC5444], this document are to help facilitate that. An extension to
such as [RFC7182], is considered to be an extension to all protocols [RFC5444], such as [RFC7182], is considered to be an extension to all
in this regard. protocols 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.
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 extended type of a TLV occupies SHOULD also be used efficiently. The Full Type of a TLV occupies two
two octets, thus there are many more available TLV extended types octets, thus there are many more available TLV Full Types than there
than there are Message Types. However, in some cases (currently are Message Types. However, in some cases (currently LINK_METRIC
LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from [RFC7182], all from [RFC7181] and ICV and TIMESTAMP from [RFC7182], all in the
in the global TLV Type space) a TLV Type with a full set of 256 TLV global TLV type space) a TLV Type with a complete set of 256 TLV Full
extended 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.
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
skipping to change at page 9, line 10 skipping to change at page 9, line 34
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. Packets and Messages 4.2. Message Multiplexing and Packets
The multiplexer has to handle message transmission and packet The multiplexer has to handle message multiplexing into packets and
multiplexing, and packet reception and message demultiplexing. The their transmission, and packet reception and demultiplexing into
multiplexer and the protocols that use it are subject to the messages. The multiplexer and the protocols that use it are subject
following rules. to the following rules.
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. latter case, other than to their hop count and hop limit fields.
This is because it enables authentication using [RFC7182], which
ignores (zeros) those two fields (only) for its end to end Message
TLV ICV (Integrity Check Value) calculations.
o Outgoing messages are then sent to the [RFC5444] multiplexer. The o Outgoing messages are then sent to the multiplexer. The owning
owning protocol MUST indicate which interface(s) the messages are protocol MUST indicate which interface(s) the messages are to be
to be sent on and their destination address, and MAY request that sent on and their destination address, and MAY request that
messages are kept together in a packet; the multiplexer SHOULD messages are kept together in a packet; the multiplexer SHOULD
respect this request if at all possible. respect this request if at all possible.
o The multiplexer SHOULD combine messages from multiple protocols o The multiplexer SHOULD combine messages from multiple protocols
that are sent on the same interface in a packet, provided that in that are sent on the same interface in a packet, provided that in
so doing the multiplexer does not cause an IP packet to exceed the so doing the multiplexer does not cause an IP packet to exceed the
current MTU (Maximum Transmission Unit). (Note that the current MTU (Maximum Transmission Unit). Note that the
multiplexer cannot fragment messages; creating suitable sized multiplexer cannot fragment messages; creating suitable sized
messages is the responsibility of the protocol generating the messages that will not cause the MTU to be exceeded if sent in a
message.) single message packet is the responsibility of the protocol
generating the message. If a larger message is created then only
IP fragmentation is available to allow the packet to be sent, 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 briefly in order to assemble
more efficient packets. It SHOULD respect any constraints on such more efficient packets. It SHOULD respect any constraints on such
delays requested by the protocol. delays requested by 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.
Separate sequence numbers SHOULD be maintained for each Separate sequence numbers MUST be maintained for each destination
destination to which packets are sent. (Note that packets travel to which packets are sent with included Packet Sequence Numbers.
one hop; the destination is therefore either a link local (Note that packets travel one hop; the destination is therefore
multicast address, if the packet is being multicast, or the either a link local multicast address, if the packet is being
address of the neighbor interface to which the packet is sent.) multicast, or the address of the neighbor interface to which the
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 and/or
the messages (for example as by [RFC7182], which MAY be used by the messages. For example [RFC7182] MAY be used by the
the multiplexer to add Packet TLVs or Message TLVs, or by the multiplexer to add Packet TLVs or Message TLVs, or by the protocol
protocol to add Message TLVs). to add Message TLVs. (Whether [RFC7182] Message TLVs are added
and verified by the multiplexer or by the protocol is an
implementation detail.)
When a packet is received, the following steps are required to be When a packet is received, the following steps are required to be
performed by the demultiplexer: performed by the demultiplexer:
o The packet and/or the messages it contains MAY be verified by an o The packet and/or the messages it contains MAY be verified by an
extension to the demultiplexer, such as [RFC7182]. extension to the demultiplexer, such as [RFC7182].
o Each message MUST be sent to its owning protocol. The o Each message MUST be sent to its owning protocol. The
demultiplexer MUST also make the Packet Header, and the source and demultiplexer MUST also make the Packet Header, and the source and
destination addresses in the IP datagram that included the packet, destination addresses in the IP datagram that included the packet,
skipping to change at page 10, line 45 skipping to change at page 11, line 34
and/or hop limit in the message. It is RECOMMENDED that these are and/or hop limit in the message. It is RECOMMENDED that these are
handled as described in Appendix B of [RFC5444]; they MUST be so handled as described in Appendix B of [RFC5444]; they MUST be so
handled if using hop count dependent TLVs such as those defined in handled if using hop count dependent TLVs such as those defined in
[RFC5497]. [RFC5497].
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
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 an o Attributes of the message, each attribute consisting of a Full
extended 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 o Attributes of each address, each attribute consisting of an Full
extended 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 extended type MAY be (and this is RECOMMENDED whenever A TLV Full Type MAY be (and this is RECOMMENDED whenever possible)
possible) defined so that there may only be one TLV of that extended defined so that there MUST only be one TLV of that Full Type
type associated with the packet (Packet TLV), message (Message TLV), associated with the packet (Packet TLV), message (Message TLV), or
or any value of any address (Address Block TLV). Note that an any value of any address (Address Block TLV). Note that an address
address may appear more than once in a message, but the restriction may appear more than once in a message, but the restriction on
on associating TLVs with addresses covers all copies of that address. associating TLVs with addresses covers all copies of that address.
It is RECOMMENDED that 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.
skipping to change at page 12, line 27 skipping to change at page 13, line 14
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.5, and
reduce the options available for message optimization described in reduce the options available for message optimization described in
Section 6. Section 6.
For example, consider NHDP's HELLO messages [RFC6130]. The basic To consider how the simple presence of an address conveying
function of a HELLO message is to indicate that an address is of a information would have restricted the development of an extension,
neighbor, using the LINK_STATUS and OTHER_NEIGHB TLVs. An extension two examples, one actual (included in the base specification, but
to NHDP might decide to use the HELLO message to report that, for could have been added later) and one hypothetical, are considered.
example, an address is one that could be used for a specialized
purpose, but not for normal NHDP-based purposes. Such an example The basic function of NHDP's HELLO messages [RFC6130] is to indicate
already exists (but within the basic specification, rather than as an that addresses are of neighbors, using the LINK_STATUS and
extension) in the use of LOST Values in the LINK_STATUS and OTHER_NEIGHB TLVs. (The message may also indicate the routers own
OTHER_NEIGHB TLVs to report that an address is of a router known not addresses, which could also serve as a further example.)
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 An extension to NHDP might decide to use the HELLO message to report
indicated by a new TLV (or a new Value of an existing TLV, see that an address is one that could be used for a specialized purpose
below). An unmodified extension to NHDP would ignore such addresses, rather than for normal NHDP-based purposes. Such an example already
as required, as it does not support that specialized purpose. If exists in the use of LOST Values in the LINK_STATUS and OTHER_NEIGHB
NHDP had been designed so that just the presence of an address TLVs to report that an address is of a router known not to be a
indicated a neighbor, that extension would not have been possible. neighbor.
A future example could be to indicate that an address is to be added
to a "blacklist" of addresses not to be used. This would use a new
TLV (or a new Value of an existing TLV, see below). Assuming that no
other TLVs are attached to such blacklisted addresses, then an
unmodified extension to NHDP would ignore those addresses, as
required. (If however, for example, a LINK_STATUS or OTHER_NEIGHB
TLV with Value LOST were also attached to that address, then the
receiving router would process that address for that TLV.) If NHDP
had been designed so that just the presence of an address indicated a
neighbor, this blacklist extension would not be possible.
Rejecting a message because it contains an unrecognized TLV Type, or Rejecting a message because it contains an unrecognized TLV Type, or
an unrecognized TLV Value, reduces the extensibility of the protocol. an unrecognized TLV Value, reduces the extensibility of the protocol.
For example, OLSRv2 [RFC7181] is, among other things, an extension to For example, OLSRv2 [RFC7181] is, among other things, an extension to
NHDP. It adds information to addresses in an NHDP HELLO message NHDP. It adds information to addresses in an NHDP HELLO message
using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP, for using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP, for
example to support Simplified Multicast Flooding (SMF) [RFC6621], example to support Simplified Multicast Flooding (SMF) [RFC6621],
must still process the HELLO message, ignoring the LINK_METRIC TLVs. must still process the HELLO message, ignoring the LINK_METRIC TLVs.
skipping to change at page 13, line 29 skipping to change at page 14, line 26
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 MUST 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.5. Information Representation
A message (excluding the Message Header) can thus be represented by This section describes a conceptual way to consider the information
two, possibly multivalued, maps: 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 is to contain. However there is no requirement that a protocol
does so. This approach may be used either to inform a protocol
design, or by a protocol (or generic parser) implementer.
o Message: (extended type) -> (length, value) A message (excluding the Message Header) can be represented by two,
possibly multivalued, maps:
o Address: (address, extended type) -> (length, value) o Message: (Full Type) -> (length, Value)
o Address: (address, Full Type) -> (length, Value)
These maps (plus a representation of the Message Header) can be the These maps (plus a representation of the Message Header) can be the
basis for a generic representation of information in a message. Such basis for a generic representation of information in a message. Such
maps can be created by parsing the message, or can be constructed maps can be created by parsing the message, or can be constructed
using the protocol rules for creating a message, and later converted using the protocol rules for creating a message, and later converted
into the octet form of the message specified in [RFC5444]. into the octet form of the message specified in [RFC5444].
While of course any implementation of software that represents While of course any implementation of software that represents
software in the above form can specify an application programming software in the above form can specify an application programming
interface (API) for that software, such an interface is not proposed interface (API) for that software, such an interface is not proposed
here. First, a full API would be programming language specific. here. First, a full API would be programming language specific.
Second, even within the above framework, there are alternative Second, even within the above framework, there are alternative
approaches to such an interface. For example, and for illustrative approaches to such an interface. For example, and for illustrative
purposes only, for the address mapping: purposes only, for the address mapping:
o Input: address and extended type. Output: list of (length, value) o Input: address and Full Type. Output: list of (length, Value)
pairs. Note that for most extended types it will be known in pairs. Note that for most Full Types it will be known in advance
advance that this list will have length zero or one. The list of that this list will have length zero or one. The list of
addresses that can be used as inputs with non-empty output would addresses that can be used as inputs with non-empty output would
need to be provided as a separate output. need to be provided as a separate output.
o Input: extended 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.6. TLVs
skipping to change at page 16, line 40 skipping to change at page 17, line 47
generating a message. Note, however, that this does not apply when generating a message. Note, however, that this does not apply when
forwarding a message, a message that is (as strongly RECOMMENDED) forwarding a message, a message that is (as strongly RECOMMENDED)
forwarded unchanged MUST have an identical octet representation, forwarded unchanged MUST have an identical octet representation,
other than that the owning protocol SHOULD increment and decrement, other than that the owning protocol SHOULD increment and decrement,
respectively, the hop count and hop limit, if present. 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. Addresses in an Address Block can be compressed, and SHOULD be.
Compression of addresses in an Address Block considers addresses to Addresses in an Address Block consist of a Head, a Mid, and a Tail,
consist of a Head, a Mid, and a Tail, where all addresses in an where all addresses in an Address Block have the same Head and Tail,
Address Block have the same Head and Tail, but different Mids. An but different Mids. Each has a length that is greater than or equal
additional compression is possible when the Tail consists of all to zero, the sum of the lengths being the address length. (The Mid
zero-valued octets. Expected use cases are IPv4 and IPv6 addresses length is deduced from this relationship.) Compression is possible
from within the same prefix and which therefore have a common Head, when the Head and/or the Tail have non-zero length. An additional
IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with compression is possible when the Tail consists of all zero-valued
a common Tail representing an interface identifier as well as having octets. Expected use cases are IPv4 and IPv6 addresses from within
a possible common Head. Note that when, for example, IPv4 addresses the same prefix and which therefore have a common Head, IPv4 subnets
have a common Head, their Tail will usually be empty. For example with a common zero-valued Tail, and IPv6 addresses with a common Tail
representing an interface identifier, as well as having a possible
common Head. Note that when, for example, IPv4 addresses have a
common Head, their Tail will usually have length zero. 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 consider:
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.
This split and/or ordering is for efficiency only, it does not This split and/or ordering is for efficiency only, it does not
provide any information. The split of the addresses affects both the provide any information. The split of the addresses affects both the
address compression and the TLV efficiency (see Section 6.2), the address compression and the TLV efficiency (see Section 6.2), the
order of the addresses within an Address Block affects only the TLV order of the addresses within an Address Block affects only the TLV
efficiency. However using more Address Blocks than is needed can efficiency. However using more Address Blocks than is needed can
increase the message size due to the overhead of each Address Block increase the message size due to the overhead of each Address Block
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 MAY 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 MAY be in separate Address Blocks.
6.2. TLVs 6.2. TLVs
The main opportunities for efficient messages when considering TLVs The main opportunities for creating more efficient messages when
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
(associating the same attribute with each address) or multivalue (associating the same attribute with each address) or multivalue
(associating a separate attribute with each address). (associating a separate attribute with each address).
The simplest to implement approach is to use multivalue TLVs that The simplest to implement approach is to use multivalue TLVs that
cover all affected addresses. However unless care is taken to order cover all affected addresses. However unless care is taken to order
addresses appropriately, these affected addresses may not all be addresses appropriately, these affected addresses may not all be
contiguous. Approaches to this are to: contiguous. Approaches to this are to:
o Reorder the addresses. It is, for example, possible (though not o Reorder the addresses. It is, for example, possible (though not
straightforward) to order all addresses in HELLO message as straightforward, and beyond the scope of this document to describe
specified in [RFC6130] so that all TLVs used only cover contiguous exactly how) to order all addresses in HELLO message as specified
in [RFC6130] so that all TLVs used only cover contiguous
addresses. This is even possible if the MPR TLV specified in addresses. This is even possible if the MPR TLV specified in
OLSRv2 [RFC7181] is added; but it is not possible, in general, if OLSRv2 [RFC7181] is added; but it is not possible, in general, if
the LINK_METRIC TLV 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. (When only one Value
skipping to change at page 18, line 31 skipping to change at page 19, line 43
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 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 (i.e., defining an UNSPECIFIED Value) is followed when
may be used by a protocol using [RFC5444]. defining any Address Block TLV with discrete Values that may be used
by a protocol using [RFC5444], and that a modified approach is used
where possible for other Address Block TLVs, as described below for
the LINK_METRIC TLV defined in [RFC7181].
It might be argued that this is not necessary in the example above, It might be argued that this (provision of an UNSPECIFIED Value to
because the addresses can be reordered. However ordering addresses allow an Address Bloc TLV to cover unaffected addresses) is not
in such a way for all possible TLVs is not, in general, possible. necessary in the example above, because the addresses can be
reordered. However ordering addresses 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
single octet Values (per address), have a Value UNSPECIFIED defined, single octet Values (per address), have a Value UNSPECIFIED defined,
as the Value 255, in [RFC7188]. A similar approach (and a similar as the Value 255, in [RFC7188]. A similar approach (and a similar
Value) is RECOMMENDED in any similar cases. Some other TLVs may need Value) is RECOMMENDED in any similar cases. Some other TLVs may need
a different approach. As noted in [RFC7188], but implicitly a different approach. As noted in [RFC7188], but implicitly
permissible before then, the LINK_METRIC TLV has two octet Values permissible before then, the LINK_METRIC TLV, defined in [RFC7181],
whose first four bits are flags indicating whether the metric applies has two octet Values whose first four bits are flags indicating
in four cases; if these are all zero then the metric does not apply whether the metric applies in four cases; if these are all zero then
in this case, which is thus the equivalent of an UNSPECIFIED Value. the metric does not apply in this case, which is thus the equivalent
of an UNSPECIFIED Value.
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
skipping to change at page 19, line 33 skipping to change at page 20, line 47
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]. This
document does not introduce any new security considerations; document does not introduce any new security considerations;
protocols designed according to these rules and recommendations are protocols designed according to these rules and recommendations are
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. [This Section may be removed
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.
10. References 10. References
10.1. Normative References 10.1. Normative References
 End of changes. 47 change blocks. 
156 lines changed or deleted 225 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/