draft-ietf-manet-rfc5444-usage-05.txt   draft-ietf-manet-rfc5444-usage-06.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 14, 2017 U. Herberg Expires: November 18, 2017 U. Herberg
H. Rogge H. Rogge
Fraunhofer FKIE Fraunhofer FKIE
April 12, 2017 May 17, 2017
Rules For Designing Protocols Using the RFC 5444 Generalized Packet/ Rules for Designing Protocols Using the RFC 5444 Generalized Packet/
Message Format Message Format
draft-ietf-manet-rfc5444-usage-05 draft-ietf-manet-rfc5444-usage-06
Abstract Abstract
RFC 5444 specifies a generalized MANET packet/message format and RFC 5444 specifies a generalized MANET packet/message format and
describes an intended use to multiplex MANET routing protocol describes an intended use for multiplexed MANET routing protocol
messages that is mandated for use on the port/protocol specified by messages that is mandated to use on the port/protocol specified by
RFC 5498. This document updates RFC 5444 by providing rules and RFC 5498. This document updates RFC 5444 by providing rules and
recommendations for how the multiplexer operates and how protocols recommendations for how the multiplexer operates and how protocols
can use the packet/message format. In particular, the mandatory can use the packet/message format. In particular, the mandatory
rules prohibit a number of uses that have been suggested in various rules prohibit a number of uses that have been suggested in various
proposals, and which would have led to interoperability problems, to proposals, and which would have led to interoperability problems, to
the impediment of protocol extension development, and to an inability the impediment of protocol extension development, and to an inability
to use optional generic parsers. to use optional generic parsers.
Status of this Memo Status of this Memo
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 14, 2017. This Internet-Draft will expire on November 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. History and Purpose . . . . . . . . . . . . . . . . . . . 3 1.1. History and Purpose . . . . . . . . . . . . . . . . . . . 3
1.2. RFC 5444 Features . . . . . . . . . . . . . . . . . . . . 3 1.2. RFC 5444 Features . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Packet/Message Format . . . . . . . . . . . . . . . . 4 1.2.1. Packet/Message Format . . . . . . . . . . . . . . . . 4
1.2.2. Multiplexing and Demultiplexing . . . . . . . . . . . 6 1.2.2. Multiplexing and Demultiplexing . . . . . . . . . . . 6
1.3. Status of This Document . . . . . . . . . . . . . . . . . 7 1.3. Status of This Document . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
4. Information Transmission . . . . . . . . . . . . . . . . . . . 8 4. Information Transmission . . . . . . . . . . . . . . . . . . . 8
4.1. Where to Record Information . . . . . . . . . . . . . . . 8 4.1. Where to Record Information . . . . . . . . . . . . . . . 8
4.2. Message and TLV Type Allocation . . . . . . . . . . . . . 8 4.2. Message and TLV Type Allocation . . . . . . . . . . . . . 9
4.3. Message Recognistion . . . . . . . . . . . . . . . . . . . 9 4.3. Message Recognition . . . . . . . . . . . . . . . . . . . 9
4.4. Message Multiplexing and Packets . . . . . . . . . . . . . 10 4.4. Message Multiplexing and Packets . . . . . . . . . . . . . 10
4.4.1. Packet Transmission . . . . . . . . . . . . . . . . . 10 4.4.1. Packet Transmission . . . . . . . . . . . . . . . . . 10
4.4.2. Packet Reception . . . . . . . . . . . . . . . . . . . 11 4.4.2. Packet Reception . . . . . . . . . . . . . . . . . . . 11
4.5. Messages, Addresses and Attributes . . . . . . . . . . . . 13 4.5. Messages, Addresses and Attributes . . . . . . . . . . . . 13
4.6. Addresses Require Attributes . . . . . . . . . . . . . . . 13 4.6. Addresses Require Attributes . . . . . . . . . . . . . . . 13
4.7. Information Representation . . . . . . . . . . . . . . . . 16 4.7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.8. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.8. Message Integrity . . . . . . . . . . . . . . . . . . . . 16
4.9. Message Integrity . . . . . . . . . . . . . . . . . . . . 17 5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 18
6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Address Block Compression . . . . . . . . . . . . . . . . 18
6.1. Address Block Compression . . . . . . . . . . . . . . . . 19
6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 21 6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 Appendix A. Information Representation . . . . . . . . . . . . . 24
Appendix B. Automation . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
[RFC5444] specifies a generalized packet/message format, designed for [RFC5444] specifies a generalized packet/message format, designed for
use by MANET routing protocols. use by MANET routing protocols.
[RFC5444] was designed following experiences with [RFC3626], which [RFC5444] was designed following experiences with [RFC3626], which
attempted, but did not quite succeed in, providing a packet/message attempted, but did not quite succeed in, providing a packet/message
format accommodating for diverse protocol extensions. [RFC5444] was format accommodating for diverse protocol extensions. [RFC5444] was
skipping to change at page 6, line 9 skipping to change at page 6, line 9
o It contains a minimal Message Header (a maximum of five elements: o It contains a minimal Message Header (a maximum of five elements:
type, originator, sequence number, hop count and hop limit) that type, originator, sequence number, hop count and hop limit) that
permit decisions whether to locally process a message, or forward permit decisions whether to locally process a message, or forward
a message (thus enabling MANET-wide flooding of a message) without a message (thus enabling MANET-wide flooding of a message) without
processing the body of the message. processing the body of the message.
1.2.2. Multiplexing and Demultiplexing 1.2.2. Multiplexing and Demultiplexing
The multiplexer (and demultiplexer) is defined in Appendix A of The multiplexer (and demultiplexer) is defined in Appendix A of
[RFC5444]. Its purpose is to allow multiple protocols to shared the [RFC5444]. Its purpose is to allow multiple protocols to share the
same IP protocol or UDP port. That sharing was made necessary by the same IP protocol or UDP port. That sharing was made necessary by the
separation of [RFC6130] from [RFC7181] as separate protocols, and by separation of [RFC6130] from [RFC7181] as separate protocols, and by
the allocation of a single IP protocol and UDP port to all MANET the allocation of a single IP protocol and UDP port to all MANET
protocols, including those protocols, following [RFC5498], which protocols, including those protocols, following [RFC5498], which
states that "All interoperable protocols running on these well-known states that "All interoperable protocols running on these well-known
IANA allocations MUST conform to [RFC5444]. [RFC5444] provides a IANA allocations MUST conform to [RFC5444]. [RFC5444] provides a
common format that enables one or more protocols to share the IANA common format that enables one or more protocols to share the IANA
allocations defined in this document unambiguously.". The allocations defined in this document unambiguously.". The
multiplexer is the mechanism in [RFC5444] that enables that sharing. multiplexer is the mechanism in [RFC5444] that enables that sharing.
skipping to change at page 8, line 38 skipping to change at page 8, line 38
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]. [RFC6130].
The third case is the normal case for a new protocol. The third case is the normal case for a new protocol.
A protocol extension may be either an update of the protocol (the A protocol extension may be either simply an update of the protocol
third case) or a new protocol (the second case). An extension to (the third case) or be a new protocol that also updates another
[RFC5444], such as [RFC7182], is considered to be an extension to all protocol (the second case). An example of the latter is that OLSRv2
protocols. Protocols SHOULD be designed to enable extension by any [RFC7181] is a protocol that also extends the HELLO message owned by
of these means to be possible, and some of the rules in this document NHDP [RFC6130]; it thus is an example of both the second and third
(in particular on Section 4.6 and xref target="integrity"/>) are to cases (the latter using the OLSRv2 owned TC message). An extension
help facilitate that. to [RFC5444], such as [RFC7182], is considered to be an extension to
all protocols. Protocols SHOULD be designed to enable extension by
any of these means to be possible, and some of the rules in this
document (in particular on Section 4.6 and Section 4.8) are to help
facilitate that.
4.2. Message and TLV Type Allocation 4.2. Message and TLV Type Allocation
Protocols SHOULD be conservative in the number of new Message Types Protocols SHOULD be conservative in the number of new Message Types
that they require, as the total available number of allocatable that they require, as the total available number of allocatable
Message Types is only 224. Protocol design SHOULD consider whether Message Types is only 224. Protocol design SHOULD consider whether
different functions can be implemented by differences in TLVs carried different functions can be implemented by differences in TLVs carried
in the same Message Type, rather than using multiple Message Types. in the same Message Type, rather than using multiple Message Types.
The TLV type space, although greater than the Message Type space, The TLV type space, although greater than the Message Type space,
skipping to change at page 9, line 22 skipping to change at page 9, line 28
global TLV type space) a TLV Type with a complete set of 256 TLV Full global TLV type space) a TLV Type with a complete set of 256 TLV Full
Types is defined (but not necessarily allocated). Types is defined (but not necessarily allocated).
Each Message Type has an associated block of Message-Type-specific Each Message Type has an associated block of Message-Type-specific
TLV Types (128 to 233, each of with 256 type extensions), both for TLV Types (128 to 233, each of with 256 type extensions), both for
Address Block TLV Types and Message TLV Types. TLV Types from within Address Block TLV Types and Message TLV Types. TLV Types from within
these blocks SHOULD be used in preference to the Message-Type- these blocks SHOULD be used in preference to the Message-Type-
independent Message TLV Types (0 to 127, each with 256 type independent Message TLV Types (0 to 127, each with 256 type
extensions) when a TLV is specific to a message. extensions) when a TLV is specific to a message.
The Expert Review guidelines in [RFC5444] are updated to include the The Expert Review guidelines in [RFC5444] are accordingly updated as
general requirement that: described in Section 8.
o The Designated Expert will consider the limited TLV and,
especially, Message Type space in considering whether a requested
allocation is allowed, and whether a more efficient allocation
than that requested is possible.
4.3. Message Recognistion 4.3. Message Recognition
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 can be recognized as one that has been previously seen A message can be recognized as one that has been previously seen
(which may determine whether it is processed and/or forwarded) if it (which may determine whether it is processed and/or forwarded) if it
contains sufficient information in its Message Header. A message contains sufficient information in its Message Header. A message
MUST be so recognized by the combination of all three of its Message MUST be so recognized by the combination of all three of its Message
skipping to change at page 10, line 34 skipping to change at page 10, line 34
to the following rules. to the following rules.
4.4.1. Packet Transmission 4.4.1. Packet Transmission
Packets are formed for transmission by: Packets are formed for transmission by:
o Outgoing messages are created by their owning protocol, and MAY be o Outgoing messages are created by their owning protocol, and MAY be
modified by any extending protocols if the owning protocol permits modified by any extending protocols if the owning protocol permits
this. Messages MAY also be forwarded by their owning protocol. this. Messages MAY also be forwarded by their owning protocol.
It is strongly RECOMMENDED that messages are not modified in the It is strongly RECOMMENDED that messages are not modified in the
latter case, other than to their hop count and hop limit fields. latter case, other than updates to their hop count and hop limit
Note that this includes having an identical octet representation, fields, as described in Section 7.1.1 of [RFC5444]. Note that
including not allowing a different TLV representation of the same this includes having an identical octet representation, including
informnation. This is because it enables end to end not allowing a different TLV representation of the same
authentication that ignores (zeros) those two fields (only), as is information. This is because it enables end to end authentication
done by for the Message TLV ICV (Integrity Check Value) that ignores (zeros) those two fields (only), as is done by for
calculations in [RFC7182]. Prototols are strongly RECOMMENDED to the Message TLV ICV (Integrity Check Value) calculations in
document their behavior with regard to modifiability of messages. [RFC7182]. Protocols are strongly RECOMMENDED to document their
behavior with regard to modifiability of messages.
o Outgoing messages are then sent to the multiplexer. The owning o Outgoing messages are then sent to the multiplexer. The owning
protocol MUST indicate which interface(s) the messages are to be protocol MUST indicate which interface(s) the messages are to be
sent on and their destination address. Note that packets travel sent on and their destination address. Note that packets travel
one hop; the destination is therefore either a link local one hop; the destination is therefore either a link local
multicast address, if the packet is being multicast, or the multicast address, if the packet is being multicast, or the
address of the neighbor interface to which the packet is sent. address of the neighbor interface to which the packet is sent.
o The owning protocol MAY request that messages are kept together in o The owning protocol MAY request that messages are kept together in
a packet; the multiplexer SHOULD respect this request if at all a packet; the multiplexer SHOULD respect this request if at all
skipping to change at page 11, line 44 skipping to change at page 11, line 47
may also add TLVs to the messages, in which case it is considered may also add TLVs to the messages, in which case it is considered
as also extended the corresponding protocols. For example as also extended the corresponding protocols. For example
[RFC7182] can be used by the multiplexer to add Packet TLVs or [RFC7182] can be used by the multiplexer to add Packet TLVs or
Message TLVs, or by the protocol to add Message TLVs. Message TLVs, or by the protocol to add Message TLVs.
4.4.2. Packet Reception 4.4.2. Packet Reception
When a packet is received, the following steps are performed by the When a packet is received, the following steps are performed by the
demultiplexer and by protocols: demultiplexer and by protocols:
o The Packet Header and the organisation into the messages that it o The Packet Header and the organization into the messages that it
contains MUST be verified by the demultiplexer. contains MUST be verified by the demultiplexer.
o The packet and/or the messages it contains MAY also be verified by o The packet and/or the messages it contains MAY also be verified by
an extension to the demultiplexer, such as [RFC7182]. an extension to the demultiplexer, such as [RFC7182].
o Each message MUST be sent to its owning protocol, or discarded if o Each message MUST be sent to its owning protocol, or discarded if
the Message Type is not recognized. The demultiplexer MUST also the Message Type is not recognized. The demultiplexer MUST also
make the Packet Header, and the source and destination addresses make the Packet Header, and the source and destination addresses
in the IP datagram that included the packet, available to the in the IP datagram that included the packet, available to the
protocol. protocol.
o The demultiplexer MUST remove any Message TLVs that were added by o The demultiplexer MUST remove any Message TLVs that were added by
an extension to the multiplexer. The message MUST be passed on to an extension to the multiplexer. The message MUST be passed on to
the protocol exactly as received from (another instance of) the the protocol exactly as received from (another instance of) the
protocol. This is in part an implementation detail. For example protocol. This is in part an implementation detail. For example
an implementation of [RFC7182] could add Message TLV either in the an implementation of [RFC7182] could add Message TLV either in the
multiplexer or in the protocol; an implemention MUST ensure that multiplexer or in the protocol; an implementation MUST ensure that
the message passed to a protocol is as it would be passed from the message passed to a protocol is as it would be passed from
that protocol by this implementation. that protocol by this implementation.
o The owning protocol MUST verify each message for correctness, it o The owning protocol MUST verify each message for correctness, it
MUST allow any extending protocol(s) to also contribute to this MUST allow any extending protocol(s) to also contribute to this
verification. verification.
o The owning protocol MUST process each message. In some cases, o The owning protocol MUST process each message. In some cases,
which will be defined in the protocol specification, this which will be defined in the protocol specification, this
processing will determine that the message MUST be ignored. processing will determine that the message MUST be ignored.
skipping to change at page 12, line 35 skipping to change at page 12, line 38
extending protocols to process the message. extending protocols to process the message.
o The owning protocol MUST manage the hop count and/or hop limit in o The owning protocol MUST manage the hop count and/or hop limit in
the message. It is RECOMMENDED that these are handled as the message. It is RECOMMENDED that these are handled as
described in Appendix B of [RFC5444]; they MUST be so handled if described in Appendix B of [RFC5444]; they MUST be so handled if
using hop count dependent TLVs such as those defined in [RFC5497]. using hop count dependent TLVs such as those defined in [RFC5497].
4.4.2.1. Other Information 4.4.2.1. Other Information
In addition to the messages between the multiplexer and the protocols In addition to the messages between the multiplexer and the protocols
in each direction, the following additional information, summarised in each direction, the following additional information, summarized
from other sections in this specification, can be exchanged. from other sections in this specification, can be exchanged.
o The packet source and destination addresses MUST be sent from o The packet source and destination addresses MUST be sent from
(de)multiplexer to protocol. (de)multiplexer to protocol.
o The Packet Header, including packet sequence number, MUST be sent o The Packet Header, including packet sequence number, MUST be sent
from (de)multiplexer to protocol if present. (An implementation from (de)multiplexer to protocol if present. (An implementation
may choose to only do so, or only report the packet sequence may choose to only do so, or only report the packet sequence
number, on request.) number, on request.)
skipping to change at page 13, line 43 skipping to change at page 13, line 47
Attributes for different addresses may be the same or different. Attributes for different addresses may be the same or different.
It is RECOMMENDED that a TLV Full Type MAY be defined so that there It is RECOMMENDED that a TLV Full Type MAY be defined so that there
MUST only be one TLV of that Full Type associated with the packet MUST only be one TLV of that Full Type associated with the packet
(Packet TLV), message (Message TLV), or any value of any address (Packet TLV), message (Message TLV), or any value of any address
(Address Block TLV). Note that an address may appear more than once (Address Block TLV). Note that an address may appear more than once
in a message, but the restriction on associating TLVs with addresses in a message, but the restriction on associating TLVs with addresses
covers all copies of that address. It is RECOMMENDED that addresses covers all copies of that address. It is RECOMMENDED that addresses
are not repeated in a message. are not repeated in a message.
A conceptual way to view this information is described in Appendix A.
4.6. Addresses Require Attributes 4.6. Addresses Require Attributes
It is not mandatory in [RFC5444] to associate an address with It is not mandatory in [RFC5444] to associate an address with
attributes using Address Block TLVs. Information about an address attributes using Address Block TLVs. Information about an address
could thus, in principle, be carried using: could thus, in principle, be carried using:
o The simple presence of an address. o The simple presence of an address.
o The ordering of addresses in an Address Block. o The ordering of addresses in an Address Block.
skipping to change at page 14, line 48 skipping to change at page 14, line 51
demultiplexer, which also MUST NOT reject a packet based on an demultiplexer, which also MUST NOT reject a packet based on an
unrecognized message; although it will reject any such messages, unrecognized message; although it will reject any such messages,
it MUST deliver any other messages in the packet to their owning it MUST deliver any other messages in the packet to their owning
protocols. protocols.
The following points indicate the reasons for these rules, based on The following points indicate the reasons for these rules, based on
considerations of extensibility and efficiency. considerations of extensibility and efficiency.
Assigning a meaning to the presence, absence or location, of an Assigning a meaning to the presence, absence or location, of an
address would reduce the extensibility of the protocol, prevent the address would reduce the extensibility of the protocol, prevent the
approach to information representation described in Section 4.7, and approach to information representation described in Appendix A, and
reduce the options available for message optimization described in reduce the options available for message optimization described in
Section 6. Section 6.
To consider how the simple presence of an address conveying To consider how the simple presence of an address conveying
information would have restricted the development of an extension, information would have restricted the development of an extension,
two examples, one actual (included in the base specification, but two examples, one actual (included in the base specification, but
could have been added later) and one hypothetical, are considered. could have been added later) and one hypothetical, are considered.
The basic function of NHDP's HELLO messages [RFC6130] is to indicate The basic function of NHDP's HELLO messages [RFC6130] is to indicate
that addresses are of neighbors, using the LINK_STATUS and that addresses are of neighbors, using the LINK_STATUS and
skipping to change at page 16, line 14 skipping to change at page 16, line 18
faulty implementation of OLSRv2 (including NHDP) creates a HELLO faulty implementation of OLSRv2 (including NHDP) creates a HELLO
message that assigns two different values of the same link metric to message that assigns two different values of the same link metric to
an address, something that is not permitted by [RFC7181]. A an address, something that is not permitted by [RFC7181]. A
receiving OLSRv2-aware implementation of NHDP will reject such a receiving OLSRv2-aware implementation of NHDP will reject such a
message, even though a receiving OLSRv2-unaware implementation of message, even though a receiving OLSRv2-unaware implementation of
NHDP will process it. This is because the OLSRv2-aware NHDP will process it. This is because the OLSRv2-aware
implementation has access to additional information, that the HELLO implementation has access to additional information, that the HELLO
message is definitely invalid, and the message is best ignored, as it message is definitely invalid, and the message is best ignored, as it
is unknown what other errors it may contain. is unknown what other errors it may contain.
4.7. Information Representation 4.7. TLVs
This section describes a conceptual way to consider the information
in a message. It may be used as the basis of an approach to parsing,
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.
A message (excluding the Message Header) can be represented by two,
possibly multivalued, maps:
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
basis for a generic representation of information in a message. Such
maps can be created by parsing the message, or can be constructed
using the protocol rules for creating a message, and later converted
into the octet form of the message specified in [RFC5444].
While of course any implementation of software that represents
software in the above form can specify an application programming
interface (API) for that software, such an interface is not proposed
here. First, a full API would be programming language specific.
Second, even within the above framework, there are alternative
approaches to such an interface. For example, and for illustrative
purposes only, for the address mapping:
o Input: address and Full Type. Output: list of (length, Value)
pairs. Note that for most Full Types it will be known in advance
that this list will have length zero or one. The list of
addresses that can be used as inputs with non-empty output would
need to be provided as a separate output.
o Input: Full Type. Output: list of (address, length, Value)
triples. As this list length may be significant, a possible
output will be of one or two iterators that will allow iterating
through that list. (One iterator that can detect the end of list,
or a pair of iterators specifying a range.)
Additional differences in the interface may relate to, for example,
the ordering of output lists.
4.8. TLVs
Within a message, the attributes are represented by TLVs. Within a message, the attributes are represented by TLVs.
Particularly for Address Block TLVs, different TLVs may represent the Particularly for Address Block TLVs, different TLVs may represent the
same information. For example, using the LINK_STATUS TLV defined in same information. For example, using the LINK_STATUS TLV defined in
[RFC6130], if some addresses have Value SYMMETRIC and some have Value [RFC6130], if some addresses have Value SYMMETRIC and some have Value
HEARD, arranged in that order, then this information can be HEARD, arranged in that order, then this information can be
represented using two single value TLVs or one multivalue TLV. The represented using two single value TLVs or one multivalue TLV. The
latter can be used even if the addresses are not so ordered. latter can be used even if the addresses are not so ordered.
A protocol MAY use any representation of information using TLVs that A protocol MAY use any representation of information using TLVs that
skipping to change at page 17, line 33 skipping to change at page 16, line 40
representation, but this is a quality of implementation issue. A representation, but this is a quality of implementation issue. A
protocol MUST recognize any permitted representation of the protocol MUST recognize any permitted representation of the
information; even if it chooses to (for example) only use multivalue information; even if it chooses to (for example) only use multivalue
TLVs, it must recognize single value TLVs (and vice versa). TLVs, it must recognize single value TLVs (and vice versa).
A protocol defining new TLVs MUST respect the naming and A protocol defining new TLVs MUST respect the naming and
organizational rules in [RFC7631]. It SHOULD follow the guidance in organizational rules in [RFC7631]. It SHOULD follow the guidance in
[RFC7188], in particular see Section 6.3. (This specification does [RFC7188], in particular see Section 6.3. (This specification does
not however relax the application of [RFC7188] where it is mandated.) not however relax the application of [RFC7188] where it is mandated.)
4.9. Message Integrity 4.8. 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 reject a message based on the inclusion Values, a protocol MUST NOT reject a message based on the inclusion
of a TLV of an unrecognized type. The protocol MUST ignore any such of a TLV of an unrecognized type. The protocol MUST ignore any such
TLVs when processing the message. The protocol MUST NOT remove or TLVs when processing the message. The protocol MUST NOT remove or
change any such TLVs if the message is to be forwarded unchanged. change any such TLVs if the message is to be forwarded unchanged.
Such behavior would have the consequences that: Such behavior would have the consequences that:
o It might disrupt the operation of an extension of which it is o It might disrupt the operation of an extension of which it is
unaware. Note that it is the responsibility of a protocol unaware. Note that it is the responsibility of a protocol
skipping to change at page 19, line 30 skipping to change at page 18, line 39
6. Message Efficiency 6. Message Efficiency
The ability to organize addresses into different, or the same, The ability to organize addresses into different, or the same,
Address Blocks, as well as to change the order of addresses within an Address Blocks, as well as to change the order of addresses within an
Address Block, and the flexibility of the TLV specification, enables Address Block, and the flexibility of the TLV specification, enables
avoiding unnecessary repetition of information, and consequently can avoiding unnecessary repetition of information, and consequently can
generate smaller messages. No algorithms for address organization or generate smaller messages. No algorithms for address organization or
compression or for TLV usage are given in [RFC5444], any algorithms compression or for TLV usage are given in [RFC5444], any algorithms
that leave the information content unchanged MAY be used when that leave the information content unchanged MAY be used when
generating a message. generating a message. See also Appendix B.
6.1. Address Block Compression 6.1. Address Block Compression
[RFC5444] allows the addresses in an Address Block to be compressed. [RFC5444] allows the addresses in an Address Block to be compressed.
A protocol generating a message SHOULD compress addresses as much as A protocol generating a message SHOULD compress addresses as much as
it can. it can.
Addresses in an Address Block consist of a Head, a Mid, and a Tail, Addresses in an Address Block consist of a Head, a Mid, and a Tail,
where all addresses in an Address Block have the same Head and Tail, where all addresses in an Address Block have the same Head and Tail,
but different Mids. Each has a length that is greater than or equal but different Mids. Each has a length that is greater than or equal
to zero, the sum of the lengths being the address length. (The Mid to zero, the sum of the lengths being the address length. (The Mid
length is deduced from this relationship.) Compression is possible length is deduced from this relationship.) Compression is possible
when the Head and/or the Tail have non-zero length. An additional when the Head and/or the Tail have non-zero length. An additional
compression is possible when the Tail consists of all zero-valued compression is possible when the Tail consists of all zero-valued
octets. Expected use cases are IPv4 and IPv6 addresses from within octets. Expected use cases are IPv4 and IPv6 addresses from within
the same prefix and which therefore have a common Head, IPv4 subnets the same prefix and which therefore have a common Head, IPv4 subnets
with a common zero-valued Tail, and IPv6 addresses with a common Tail with a common zero-valued Tail, and IPv6 addresses with a common Tail
representing an interface identifier, as well as having a possible representing an interface identifier, as well as having a possible
common Head. Note that when, for example, IPv4 addresses have a common Head. Note that when, for example, IPv4 addresses have a
common Head, their Tail will usually have length zero. For example common Head, their Tail will usually have length zero.
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. For example:
o The IPv4 addresses 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.
o The IPv6 addresses 2001:DB8:prefix1:interface and 2001:DB8:
prefix2:interface that use the same interface identifier but
completely different prefixes (except as noted) would, for
greatest efficiency, have a 4 octet head, a 4 octet Mid, and an 8
octet Tail. (They could have a larger Head and/or Tail and a
smaller Mid if the prefixes have any octets in common.)
Putting addresses into a message efficiently also has to consider: 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
skipping to change at page 22, line 21 skipping to change at page 21, line 40
defined length for that TLV Type, then the following rules are defined length for that TLV Type, then the following rules are
adopted: adopted:
o If the received single-length is greater than the expected single- o If the received single-length is greater than the expected single-
length, then the excess octets MUST be ignored. length, then the excess octets MUST be ignored.
o If the received single-length is less than the expected single- o If the received single-length is less than the expected single-
length, then the absent octets MUST be considered to have all bits length, then the absent octets MUST be considered to have all bits
cleared (0). cleared (0).
6.4. Automation
There is scope for creating a protocol-independent optimizer for
[RFC5444] messages that performs appropriate address re-organization
(ordering and Address Block separation) and TLV changes (of number,
single- or multi- valuedness and use of unspecified values) to create
more compact messages. The possible gain depends on the efficiency
of the original message creation, and the specific details of the
message. Note that this process cannot be TLV Type independent, for
example a LINK_METRIC TLV has a more complicated Value structure than
a LINK_STATUS TLV does if using UNSPECIFIED Values.
Such a protocol-independent optimizer MAY be used by the router
generating a message, but MUST NOT be used on a message that is
forwarded unchanged by a router.
7. Security Considerations 7. Security Considerations
This document does not specify a protocol, but provides rules and This document does not specify a protocol, but provides rules and
recommendations for how to design protocols using [RFC5444], whose recommendations for how to design protocols using [RFC5444], whose
security considerations apply. security considerations apply.
If the recommendation in Section 4.4.1 that messages are not modified If the recommendation in Section 4.4.1 that messages are not modified
(except for hop count and hop limit) when forwarded is followed, then (except for hop count and hop limit) when forwarded is followed, then
the security framework for [RFC5444] specified in [RFC7182] can be the security framework for [RFC5444] specified in [RFC7182] can be
used in full. If that recommendation is not followed, then the used in full. If that recommendation is not followed, then the
skipping to change at page 22, line 48 skipping to change at page 22, line 4
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], whose recommendations for how to design protocols using [RFC5444], whose
security considerations apply. security considerations apply.
If the recommendation in Section 4.4.1 that messages are not modified If the recommendation in Section 4.4.1 that messages are not modified
(except for hop count and hop limit) when forwarded is followed, then (except for hop count and hop limit) when forwarded is followed, then
the security framework for [RFC5444] specified in [RFC7182] can be the security framework for [RFC5444] specified in [RFC7182] can be
used in full. If that recommendation is not followed, then the used in full. If that recommendation is not followed, then the
Packet TLVs from [RFC7182] can be used, but the Message TLVs from Packet TLVs from [RFC7182] can be used, but the Message TLVs from
[RFC7182] cannot be used as intended. [RFC7182] cannot be used as intended.
In either case, a protocol using [RFC5444] MUST document whether it In either case, a protocol using [RFC5444] MUST document whether it
is using [RFC7182] and if so, how. is using [RFC7182] and if so, how.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. [This Section may be removed The Expert Review guidelines in [RFC5444] are updated to include the
by the RFC Editor.] general requirement that:
o The Designated Expert will consider the limited TLV and,
especially, Message Type space in considering whether a requested
allocation is allowed, and whether a more efficient allocation
than that requested is possible.
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
skipping to change at page 25, line 16 skipping to change at page 24, line 16
[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 7188, Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
April 2014. April 2014.
[RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for [RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for
the Optimized Link State Routing Protocol Version 2 the Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7722, December 2015. (OLSRv2)", RFC 7722, December 2015.
Appendix A. Information Representation
This section describes a conceptual way to consider the information
in a message. It may be used as the basis of an approach to parsing,
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.
A message (excluding the Message Header) can be represented by two,
possibly multivalued, maps:
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
basis for a generic representation of information in a message. Such
maps can be created by parsing the message, or can be constructed
using the protocol rules for creating a message, and later converted
into the octet form of the message specified in [RFC5444].
While of course any implementation of software that represents
software in the above form can specify an application programming
interface (API) for that software, such an interface is not proposed
here. First, a full API would be programming language specific.
Second, even within the above framework, there are alternative
approaches to such an interface. For example, and for illustrative
purposes only, for the address mapping:
o Input: address and Full Type. Output: list of (length, Value)
pairs. Note that for most Full Types it will be known in advance
that this list will have length zero or one. The list of
addresses that can be used as inputs with non-empty output would
need to be provided as a separate output.
o Input: Full Type. Output: list of (address, length, Value)
triples. As this list length may be significant, a possible
output will be of one or two iterators that will allow iterating
through that list. (One iterator that can detect the end of list,
or a pair of iterators specifying a range.)
Additional differences in the interface may relate to, for example,
the ordering of output lists.
Appendix B. Automation
There is scope for creating a protocol-independent optimizer for
[RFC5444] messages that performs appropriate address re-organization
(ordering and Address Block separation) and TLV changes (of number,
single- or multi- valuedness and use of unspecified values) to create
more compact messages. The possible gain depends on the efficiency
of the original message creation, and the specific details of the
message. Note that this process cannot be TLV Type independent, for
example a LINK_METRIC TLV has a more complicated Value structure than
a LINK_STATUS TLV does if using UNSPECIFIED Values.
Such a protocol-independent optimizer MAY be used by the router
generating a message, but MUST NOT be used on a message that is
forwarded unchanged by a router.
Authors' Addresses Authors' Addresses
Thomas Clausen Thomas Clausen
Ecole Polytechnique 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
 End of changes. 27 change blocks. 
120 lines changed or deleted 139 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/