RFC 6130
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
12. HELLO Message Processing
On receiving a HELLO message, a router MUST first check if the message is invalid for processing by this router, as defined in Section 12.1 and, if so, discard the message without further processing. Otherwise, for each received and valid HELLO message, the receiving router MUST update its appropriate Interface Information Base and its Neighbor Information Base as specified in Section 12.3 to Section 12.6. These updates MUST be performed in the order in which they are presented in this specification. If any changes satisfy any of the conditions described in Section 13, then the indicated consequences in that section MUST be applied immediately, unless noted otherwise. All message processing, including determination of whether a message is invalid, considers only TLVs with Type Extension = 0. TLVs with any other type extension are ignored. All references to, for example, a TLV with Type = LINK_STATUS refer to a TLV with Type = LINK_STATUS and Type Extension = 0.12.1. Invalid Message
A received HELLO message is invalid for processing by this router if any of the following conditions are true: o The address length as specified in the Message Header is not equal to the length of the addresses used by this router. o The message has a <msg-hop-limit> field in its Message Header with a value other than one. (Note that the message does not need to have a <msg-hop-limit> field.)
o The message has a <msg-hop-count> field in its Message Header with
a value other than zero. (Note that the message does not need to
have a <msg-hop-count> field.)
o The message does not have a Message TLV with Type = VALIDITY_TIME
in its Message TLV Block.
o The message has more than one Message TLV with Type =
VALIDITY_TIME in its Message TLV Block.
o The message has more than one Message TLV with Type =
INTERVAL_TIME in its Message TLV Block.
o The message has any Address Block TLV(s) with Type = LOCAL_IF and
any single Value v such that v != THIS_IF and v != OTHER_IF.
o Any address object (including different address objects
representing the same network address, in the same or different
Address Blocks) is associated with more than one Value by one or
more Address Block TLV(s) with Type = LOCAL_IF.
o Any address object (henceforth local address) associated with an
Address Block TLV with Type = LOCAL_IF represents one of the
receiving router's current or recently used network addresses
(i.e., local address overlaps any network address in any
I_local_iface_addr_list in the Local Interface Set or any
IR_local_iface_addr in the Removed Interface Address Set).
o The message has any Address Block TLV(s) with Type = LINK_STATUS
with any single Value v such that v != LOST, v != SYMMETRIC, and v
!= HEARD.
o The message has any Address Block TLV(s) with Type = OTHER_NEIGHB
with any single Value v such that v != LOST and v != SYMMETRIC.
o Any address object (including different copies of an address
object, in the same or different Address Blocks) is associated
with an Address Block TLV with Type = LOCAL_IF and with an Address
Block TLV with Type = LINK_STATUS.
o Any address object (including different copies of an address
object, in the same or different Address Blocks) is associated
with an Address Block TLV with Type = LOCAL_IF and with an Address
Block TLV with Type = OTHER_NEIGHB.
o Any address object (including different copies of an address
object, in the same or different Address Blocks) is associated
with more than one Value by one or more Address Block TLVs with
Type = LINK_STATUS.
o Any address object (including different copies of an address
object, in the same or different Address Blocks) is associated
with more than one Value by one or more Address Block TLVs with
Type = OTHER_NEIGHB.
A router MAY recognize additional reasons for identifying that a
message is badly formed and therefore invalid for processing, e.g.,
to allow a security protocol as suggested in Section 17 to perform
verification of HELLO message signatures and prevent processing of
unverifiable HELLO messages by this protocol.
An invalid message MUST be silently discarded, without updating the
router's Information Bases.
12.2. Definitions
For the purpose of this section, note the following definitions:
o "validity time" is calculated from the Message TLV with Type =
VALIDITY_TIME of the HELLO message as specified in [RFC5497].
(Note that, as specified by Section 12.1, there must be exactly
one such Message TLV in the HELLO message.) All information in
the HELLO message used by this specification has the same validity
time.
o "Receiving Address List" is the I_local_iface_addr_list
corresponding to the MANET interface on which the HELLO message
was received
o "Sending Address List" is an unordered list of network addresses
of the MANET interface over which the HELLO message was sent,
i.e., is an unordered list of the network addresses represented by
address objects contained in the HELLO message with an associated
Address Block TLV with Type = LOCAL_IF and Value = THIS_IF. If
the Sending Address List is otherwise empty, then the Sending
Address List contains a single network address with maximum prefix
length (i.e., /32 for IPv4, /128 for IPv6) with an address equal
to the sending address of the IP datagram in which the HELLO
message was included.
o "Neighbor Address List" is an unordered list of all the network
addresses of all the interfaces of the router that generated the
HELLO message, i.e., is the Sending Address List, plus the network
addresses represented by address objects contained in the HELLO
message with an associated Address Block TLV with Type = LOCAL_IF
and Value = OTHER_IF.
o "EXPIRED" indicates that a timer is set to a value clearly
preceding the current time (e.g., current time - 1).
o "Removed Address List" is a list of network addresses created by
this HELLO message processing that were formerly reported as local
by the router originating the HELLO message but that are not
included in the Neighbor Address List. This list is initialized
as empty.
o "Lost Address List" is a subset of the Removed Address List
containing network addresses that were formerly considered as
symmetric. This list is initialized as empty.
12.3. Updating the Neighbor Set
On receiving a HELLO message, the router MUST update its Neighbor Set
and populate the Removed Address List and Lost Address List:
1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples)
where N_neighbor_addr_list contains any network address that
overlaps with any network address in the Neighbor Address List.
2. If there are no matching Neighbor Tuples, then:
1. Create a new Neighbor Tuple with:
o N_neighbor_addr_list := Neighbor Address List;
o N_symmetric := false.
3. If there is one matching Neighbor Tuple, then:
1. If the matching Neighbor Tuple's N_neighbor_addr_list !=
Neighbor Address List, then:
1. For each network address (henceforth removed address)
that is contained in that N_neighbor_addr_list but that
is not contained in the Neighbor Address List:
1. Add the removed address to the Removed Address List.
2. If N_symmetric = true, then add the removed address
to the Lost Address List.
2. Update the matching Neighbor Tuple by:
o N_neighbor_addr_list := Neighbor Address List.
4. If there are two or more matching Neighbor Tuples, then:
1. For each network address (henceforth removed address) that is
contained in the N_neighbor_addr_list of any of the matching
Neighbor Tuples but is not contained in the Neighbor Address
List:
1. Add removed address to the Removed Address List.
2. If N_symmetric = true, then add removed address to the
Lost Address List.
2. Replace the matching Neighbor Tuples by a single Neighbor
Tuple with:
o N_neighbor_addr_list := Neighbor Address List;
o N_symmetric := false
12.4. Updating the Lost Neighbor Set
On receiving a HELLO message, a router MUST update its Lost Neighbor
Set:
1. For each network address (henceforth lost address) that is
contained in the Lost Address List, if no Lost Neighbor Tuple
with NL_neighbor_addr = lost address exists, then add a Lost
Neighbor Tuple with:
o NL_neighbor_addr := lost address;
o NL_time := current time + N_HOLD_TIME.
12.5. Updating the Link Sets
On receiving a HELLO message, a router MUST update its Link Sets:
1. Remove all network addresses in the Removed Address List from the
L_neighbor_iface_addr_list of all Link Tuples.
2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now
empty; apply Section 13.2 but not Section 13.3.
The router MUST then update its Link Set for the MANET interface on
which the HELLO message is received:
1. Find all Link Tuples (henceforth matching Link Tuples) where:
o L_neighbor_iface_addr_list contains one or more network
addresses in the Sending Address List.
2. If there is more than one matching Link Tuple, then remove them
all; apply Section 13.2 but not Section 13.3.
3. If no matching Link Tuples remain, then create a new matching
Link Tuple with:
o L_neighbor_iface_addr_list := empty;
o L_HEARD_time := EXPIRED;
o L_SYM_time := EXPIRED;
o L_quality := INITIAL_QUALITY;
o L_pending := INITIAL_PENDING;
o L_lost := false;
o L_time := current time + validity time.
4. The matching Link Tuple, existing or new, is then modified as
follows:
1. If the router finds any network address (henceforth receiving
address) in the Receiving Address List in an Address Block in
the HELLO message, then the Link Tuple is modified as
follows:
1. If any receiving address in the HELLO message is
associated with an Address Block TLV with Type =
LINK_STATUS and with Value = HEARD or Value = SYMMETRIC,
then:
o L_SYM_time := current time + validity time.
2. Otherwise, if any receiving address in the HELLO message
is associated with an Address Block TLV with Type =
LINK_STATUS and Value = LOST, then:
1. if L_SYM_time has not expired, then:
1. L_SYM_time := EXPIRED.
2. if L_status = HEARD, then:
o L_time := current time + L_HOLD_TIME.
2. L_neighbor_iface_addr_list := Sending Address List.
3. L_HEARD_time := max(current time + validity time,
L_SYM_time).
4. If L_status = PENDING, then:
o L_time := max(L_time, L_HEARD_time).
5. Otherwise, if L_status = HEARD or L_status = SYMMETRIC, then:
o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).
12.6. Updating the 2-Hop Set
On receiving a HELLO message, a router MUST update its 2-Hop Set for
the MANET interface on which the HELLO message was received:
1. Remove all network addresses in the Removed Address List from the
N2_neighbor_iface_addr_list of all 2-Hop Tuples.
2. If the Link Tuple whose L_neighbor_iface_addr_list = Sending
Address List, has L_status = SYMMETRIC, then:
1. For each network address (henceforth 2-hop address) in an
Address Block of the HELLO message, where:
o a 2-hop address is not contained in the Neighbor Address
List;
o a 2-hop address is not contained in any
I_local_iface_addr_list; AND
o a 2-hop address != any IR_local_iface_addr
perform the following processing:
1. If the 2-hop address has an associated Address Block TLV
with:
o Type = LINK_STATUS and Value = SYMMETRIC; OR
o Type = OTHER_NEIGHB and Value = SYMMETRIC,
then, if there is no 2-Hop Tuple such that:
o N2_neighbor_iface_addr_list contains one or more
network addresses in the Sending Address List; AND
o N2_2hop_addr = 2-hop address,
then create a 2-Hop Neighbor Tuple with:
o N2_2hop_addr := 2-hop address.
This 2-Hop Tuple (existing or new) is then modified as
follows:
o N2_neighbor_iface_addr_list := Sending Address List;
o N2_time := current time + validity time.
2. Otherwise, if a 2-hop address has an Address Block TLV
with:
o Type = LINK_STATUS and Value = LOST or Value = HEARD;
OR
o Type = OTHER_NEIGHB and Value = LOST;
then remove all 2-Hop Tuples with:
o N2_neighbor_iface_addr_list containing one or more
network addresses in the Sending Address List; AND
o N2_2hop_addr = 2-hop address.
13. Other Information Base Changes
The Interface and Neighbor Information Bases MUST be changed when
certain events occur. These events may result from HELLO message
processing or may be otherwise generated (e.g., expiry of timers or
link quality changes).
Events that cause changes in the Information Bases are:
o A Link Tuple's L_status changes to SYMMETRIC. In this case, the
actions specified in Section 13.1 are performed.
o A Link Tuple's L_status changes from SYMMETRIC, or the Link Tuple
is removed. In this case, the actions specified in Section 13.2
are performed.
o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed.
In this case, the actions specified in Section 13.3 are performed.
o Local interface network address changes. In this case, the
actions specified in Section 9 are performed.
o Link quality changes. In this case, the actions specified in
Section 14 are performed.
If a Link Tuple is removed, or if L_status changes from SYMMETRIC and
L_HEARD_time expires, then the actions specified in Section 13.2 MUST
be performed before the actions specified in Section 13.3 are
performed for that Link Tuple.
A router MAY report updated information in response to any of these
changes in HELLO message(s), subject to the constraints in
Section 11.
A router that transmits HELLO messages in response to such changes
SHOULD transmit a HELLO message:
o On all MANET interfaces, if the Neighbor Set changes such as to
indicate the change in symmetry of any 1-hop neighbors (including
addition or removal of symmetric 1-hop neighbors).
o Otherwise, on all those MANET interfaces whose Link Set changes
such as to indicate a change in L_status of any 1-hop neighbors
(including the addition or removal of any 1-hop neighbors, other
than those considered pending).
13.1. Link Tuple Symmetric
If, for any Link Tuple that does not have L_status = SYMMETRIC:
o L_status changes to SYMMETRIC;
then:
1. For the Neighbor Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list, set:
o N_symmetric := true.
2. Remove all Lost Neighbor Tuples whose NL_neighbor_addr is
contained in that N_neighbor_addr_list.
This includes any newly created Link Tuples whose status is
immediately updated such that L_status = SYMMETRIC. (Note that in
this specification, all Link Tuples are created such that their
L_status is not SYMMETRIC, but a Link Tuple may be immediately
updated by subsequent processing of the same HELLO message that
caused the creation of the Link Tuple such that the Link Tuple's
L_status changes to SYMMETRIC.)
13.2. Link Tuple Not Symmetric
If for any Link Tuple with L_status = SYMMETRIC:
o L_status changes to any other value; OR
o the Link Tuple is removed;
then:
1. All 2-Hop Tuples for the same MANET interface with:
o N2_neighbor_iface_addr_list contains one or more network
addresses in L_neighbor_iface_addr_list;
are removed.
2. For the Neighbor Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list:
1. If there are no remaining Link Tuples for any MANET interface
where:
o L_neighbor_iface_addr_list is contained in
N_neighbor_addr_list; AND
o L_status = SYMMETRIC;
then modify the Neighbor Tuple by:
1. N_symmetric := false.
2. For each network address (henceforth neighbor address) in
N_neighbor_addr_list, add a Lost Neighbor Tuple with:
o NL_neighbor_addr := neighbor address;
o NL_time := current time + N_HOLD_TIME.
13.3. Link Tuple Heard Timeout
If, for any Link Tuple:
o L_HEARD_time expires; OR
o the Link Tuple is removed;
then:
1. For the Neighbor Tuple whose N_neighbor_addr_list contains
L_neighbor_iface_addr_list, if no Link Tuples for any MANET
interface remain where:
o L_neighbor_iface_addr_list is contained in
N_neighbor_addr_list; AND
o L_HEARD_time is not expired;
then remove the Neighbor Tuple.
14. Link Quality
Link quality is a mechanism whereby a router MAY take considerations
other than message exchange into account for determining when a link
is and is not a candidate for being considered as HEARD or SYMMETRIC.
As such, it is a "link admission" mechanism.
Link quality information for a link is generated (e.g., through
access to signal to noise ratio, packet loss rate, or other
information from the link layer) and used only locally, i.e., is not
included in signaling, and routers may interoperate whether they are
using the same, different, or no, link quality information. Link
quality information is specified as a normalized, dimensionless
figure in the interval zero to one, inclusive, a higher value
indicating a better link quality.
For deployments where no link quality is used, the considerations in
Section 14.1 apply. For deployments where link quality is used, the
general principles of link quality usage are described in
Section 14.2. Sections 14.3 and 14.4 detail link quality
functioning.
14.1. Deployment without Link Quality
In order for a router to not employ link quality, the router MUST define: o INITIAL_PENDING := false; o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define INITIAL_QUALITY := 1).14.2. Basic Principles of Link Quality
To enable link quality usage, the L_quality value of a Link Tuple is used in conjunction with two thresholds, HYST_ACCEPT and HYST_REJECT, to set the flags L_pending and L_lost of that Link Tuple. Based on these flags, the link status to advertise for that Link Tuple is determined as described in Section 7.1. The use of two thresholds implements link hysteresis, whereby a link that has HYST_REJECT <= L_quality < HYST_ACCEPT may be either accepted or rejected (depending on which threshold it has most recently crossed, or, if neither, on the value of parameter INITIAL_PENDING). With appropriate values of these parameters, this prevents overly rapid changes of link status. The basic principles of link quality usage are as follows: o A router does not advertise a neighbor interface in any state until L_quality is acceptable: o If INITIAL_PENDING = true, then the link is advertised when link L_quality >= HYST_ACCEPT. o Otherwise, the link is advertised when L_quality >= HYST_REJECT. A link that is not yet advertised has L_pending = true. o Once L_quality >= HYST_ACCEPT, the router sets L_pending := false, indicating that the link can be advertised. o A link for which L_pending = false is advertised until its L_quality drops below HYST_REJECT. o If a link has L_pending = false and L_quality < HYST_REJECT, the link is LOST and is advertised as such. This link is not reconsidered as a candidate HEARD or SYMMETRIC link until L_quality >= HYST_ACCEPT.
o A link that has an acceptable quality may be advertised as HEARD,
SYMMETRIC or LOST according to the exchange of HELLO messages.
In order that these principles can all hold, a router MUST NOT
define:
o INITIAL_PENDING = false and INITIAL_QUALITY < HYST_REJECT; OR
o INITIAL_PENDING = true and INITIAL_QUALITY >= HYST_ACCEPT.
14.3. When Link Quality Changes
If L_quality for a link changes, then the following actions MUST be
taken:
1. If L_quality >= HYST_ACCEPT, then the corresponding Link Tuple is
modified by:
1. L_pending := false;
2. L_lost := false;
3. If L_status = HEARD or L_status = SYMMETRIC, then:
o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).
2. If L_status != PENDING, and L_quality < HYST_REJECT, then the
corresponding Link Tuple is modified by:
1. If L_lost = false, then:
o L_lost := true;
o L_time := min(L_time, current time + L_HOLD_TIME).
As a result of this processing, the L_STATUS of a Link Tuple may
change. In this case, the processing actions corresponding to this
change, as specified in Section 13, MUST also be taken.
If L_quality for a link is updated based on HELLO message reception,
or on reception of a packet including a HELLO message, then L_quality
MUST be updated prior to the HELLO message processing described in
Section 12. (If the receipt of the HELLO message, or the packet
containing it, creates the Link Tuple, then the Link Tuple MUST be
created with the appropriately updated L_quality value, rather than
with L_quality := INITIAL_QUALITY.)
14.4. Updating Link Quality
A router MAY update link quality based on any information available to it. Particular cases that MAY be used include: o Information from the link layer, such as signal-to-noise ratio or packet acknowledgment reception and loss information. o Receipt or loss of control packets. If control packets include a sequential packet sequence number, as defined in [RFC5444], then link quality can be updated when a control packet is received, whether or not it contains a HELLO message. The link quality may then, for example, be based on whether the last N out of M control packets on the link were received, or may use a "leaky integrator" tracking packet reception and loss. o Receipt or loss of HELLO messages. If the maximum interval between HELLO messages is known (such as by inclusion in HELLO messages of a Message TLV with Type := INTERVAL_TIME, as defined in [RFC5497]), then the loss of HELLO messages can be determined without the need to receive a later HELLO message. Note that if this case is combined with the previous case, then care must be taken to avoid "double counting" a lost HELLO message in a lost packet.15. Proposed Values for Parameters and Constants
This section lists the parameters and constants used in the specification of the protocol, and proposed values of each that MAY be used when a single value of each is used.15.1. Message Interval Interface Parameters
o HELLO_INTERVAL := 2 seconds o HELLO_MIN_INTERVAL := HELLO_INTERVAL/4 o REFRESH_INTERVAL := HELLO_INTERVAL15.2. Information Validity Time Interface Parameters
o H_HOLD_TIME := 3 x REFRESH_INTERVAL o L_HOLD_TIME := H_HOLD_TIME
15.3. Information Validity Time Router Parameters
o N_HOLD_TIME := L_HOLD_TIME o I_HOLD_TIME := N_HOLD_TIME15.4. Link Quality Interface Parameters
If link quality is changed, then parameter values will depend on the link quality process. If link quality is not changed, then: o HYST_ACCEPT := 1 o HYST_REJECT := 0 o INITIAL_QUALITY := 1 o INITIAL_PENDING := false15.5. Jitter Interface Parameters
o HP_MAXJITTER := HELLO_INTERVAL/4 o HT_MAXJITTER := HP_MAXJITTER15.6. Constants
o C := 1/1024 second16. Usage with Other Protocols
Other protocols, such as MANET routing protocols, that use neighborhood discovery, may need to interact with this protocol. This protocol is designed to permit such interactions, in particular: o Through accessing, and possibly extending, the information in the Local Information Base (Section 6), the Interface Information Base (Section 7), and the Neighbor Information Base (Section 8). These Information Bases record the interface configuration of the router, as well as the local connectivity, up to two hops away. All updates to the elements specified in this document are subject to the constraints specified in Appendix B. o Through accessing an outgoing HELLO message prior to it being transmitted over any MANET interface, and to add information (e.g., TLVs) as specified in [RFC5444]. This may, for example, be to allow a security protocol, as suggested in Section 17, to add a TLV containing a cryptographic signature to the message, or be to
allow inserting relay selection information into a HELLO message
by way of adding a TLV to an outgoing HELLO message prior to it
being transmitted.
o Through accessing an incoming HELLO message, and potentially
discarding it prior to processing by this protocol. This may, for
example, allow a security protocol as suggested in Section 17 to
perform verification of HELLO message signatures and prevent
processing of unverifiable HELLO messages by this protocol.
o Through accessing an incoming HELLO message after it has been
completely processed by this protocol. This may, in particular,
allow a protocol that has added information, such as relay
selection information by way of inclusion of appropriate TLVs,
access to such information after appropriate updates have been
recorded in the Information Bases in this protocol.
o Through requesting that a HELLO message be generated at a specific
time. In that case, HELLO message generation MUST still respect
the constraints in Appendix B.
Address objects in HELLO messages are processed according to their
associated Address Block TLVs. All such address objects are to be
processed according to this specification are associated with Address
Block TLVs with Type of LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS (and
type extension zero). Address objects not associated with an Address
Block TLV of any of these Types are therefore not processed by the
protocol described in this specification.
A protocol, such as a MANET routing protocol, interacting with this
protocol may need to add information to HELLO messages. This may be
in the form of associating TLVs (of Type other than LOCAL_IF,
OTHER_NEIGHB, or LINK_STATUS) to address objects already included by
this specification.
A protocol, such as a MANET routing protocol, interacting with this
protocol may also add information to HELLO messages by inserting
address objects not already included by this specification. Such
address objects are in the following called "inserted addresses".
These inserted addresses may added to Address Blocks already present
by virtue of the HELLO message generation in this specification, or
may appear in new Address Blocks. In both cases, the following MUST
be observed:
o An inserted address MUST NOT be associated with an Address Block
TLV of Type LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS. Consequently,
the processing in this specification will ignore such address
objects.
o Each inserted address MUST be associated with an Address Block
TLV, to be defined by the specification of the protocol inserting
the address object. In this way, all addresses present in a HELLO
message are associated with an Address Block TLV defining their
semantics.
Informally speaking, Address Block TLVs define the semantics of
address objects in an Address Block. If an address object in an
Address Block does not have any Address Block TLVs associated, that
address object has no semantics. Consequently, all protocols using
the protocol defined in this specification MUST respect the
following:
o An address object in an Address Block, which is not associated
with any Address Block TLV, MUST be silently ignored; the mere
presence of an address object without an associated Address Block
TLV in a HELLO message MUST NOT cause any processing.
A protocol interacting with this protocol MAY also add an originator
address to HELLO messages, as specified in [RFC5444]. Such an
originator address MUST be unique to the originating router, it MAY
be a local interface address of the router. It SHOULD be used
consistently, but SHOULD NOT be constrained in any other way.
Strict adherence to these points will enable unambiguous coexistence
of future "extensions" to HELLO messages.
In some cases, a protocol interacting with the protocol defined in
this specification, may need to recognize which HELLO messages to
process and which HELLO messages to discard. It is the
responsibility of that protocol to ensure that such messages are
suitably identifiable, e.g., through inclusion of a Message TLV or
through recognizing an administrative configuration (such as address
ranges). Note that such a protocol interacting with this protocol
MAY specify such interaction by recognizing an additional reason for
discarding a message. As suggested in Section 17 this might, for
example, be a security protocol discarding a message that does not
carry a Message TLV containing a cryptographic signature.
17. Security Considerations
The objective of this protocol is to allow each router in the network
to acquire information describing its 1-hop neighborhood and
symmetric 2-hop neighborhood. This is acquired through HELLO message
exchange between neighboring routers. This information is made
available through the Interface Information Bases and Neighbor
Information Base, describing the router's 1-hop neighborhood and
symmetric 2-hop neighborhood.
Under normal circumstances, the information recorded in these Information Bases is correct, i.e., corresponds to the actual network topology, apart from any changes that have not (yet) been tracked by the HELLO message exchanges. If a router for some reason, whether malice or malfunction, transmits invalid HELLO messages, incorrect information may be recorded in other routers' Information Bases. This protocol specification does, however, prevent inconsistent information from being included in the Information Bases through the specified processing, which maintains the constraints in Appendix B. The exact consequence of information inexactness depends on the use of these Information Bases, and SHOULD therefore be reflected in the specification of protocols that use information provided by this neighborhood discovery protocol. This section, therefore, firstly outlines the ways in which correctly formed, but still invalid, HELLO messages may appear, in Section 17.1. Injection of invalid HELLO messages into a network may be prevented in a number of ways. If, for example, a network is deployed in a site to which access is strictly regulated, so that physical access and proximity to the network is prevented, then further security mechanisms to protect against malicious routers injecting invalid HELLO messages may not be required. Similarly, if the link layer over which the network is formed provides appropriate confidentiality, authentication, and integrity, then this may, for a given deployment, suffice to appropriately protect against disclosure of information to an eavesdropper, and against a malicious router injecting invalid HELLO messages. In the latter case, the link layer would discard frames that fail the link-layer checks, without attempting to deliver such frames to IP. Finally, certain usage may be of a nature where disruption of service is of no consequence, or at least not of sufficient consequence to warrant deployment of additional security mechanisms. A further point to stress, and which follows from the discussions above is, that it will not be the case that "one size security fits all". Different deployments may have different requirements. For example, in a deployment of a low-value sensor network, authentication using a simple message authentication code and shared symmetric keys may suffice, while anything beyond that may require too many computational resources to be viable. Conversely, in, for example, a community network, verifying not only that the originator of a HELLO message "has the right key" but also the precise identity of the originator may be required to be proved, and computational resources may be available to make such a requirement feasible.
Section 17.2, therefore, does not specify a single "one-size-fits- all" mechanism, but rather details how the security suggestions in [RFC5444] are considered for applicability within the context of this protocol, and with the purpose of aiding deployment-specific security mechanisms to be developed.17.1. Invalid HELLO Messages
A correctly formed, but still invalid, HELLO message may take any of the following forms. Note that a present or absent address object in an Address Block, does not by itself cause a problem. It is the presence, absence, or incorrectness of associated LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Address Block TLVs that causes problems. A router may provide false information about its own identity: o The HELLO message may contain address objects with an associated LOCAL_IF Address Block TLV that do not correspond to addresses of interfaces of the router transmitting the HELLO message. o The HELLO message may omit network addresses, or their associated LOCAL_IF Address Block TLV, of interfaces of the router transmitting the HELLO message (other than the allowed omission of the only local interface network address of the MANET interface over which the HELLO message is transmitted, if that is the case). o The HELLO message may incorrectly specify the LOCAL_IF Address Block TLV Value associated with one or more local interface network addresses, indicating incorrectly whether they are associated with the MANET interface over which the HELLO message is transmitted. A router may provide false information about the identity of other routers: o A present LINK_STATUS Address Block TLV may, incorrectly, identify a network address as being of a MANET interface that is or was heard on the MANET interface over which the HELLO message is transmitted. o A consistently absent LINK_STATUS Address Block TLV may, incorrectly, fail to identify a network address as being of a MANET interface that is or was heard on the MANET interface over which the HELLO message is transmitted.
o A present OTHER_NEIGHB Address Block TLV may, incorrectly,
identify a network address as being of a router that is or was
in the sending router's symmetric 1-hop neighborhood.
o A consistently absent OTHER_NEIGHB Address Block TLV may,
incorrectly, fail to identify a network address as being of a
router that is or was in the sending router's symmetric 1-hop
neighborhood.
o The Value of a LINK_STATUS Address Block TLV may incorrectly
indicate the status (LOST, SYMMETRIC or HEARD) of the link from
a 1-hop neighbor.
o The Value of an OTHER_NEIGHB Address Block TLV may incorrectly
indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop
neighbor.
17.2. Authentication, Integrity, and Confidentiality Suggestions
The security suggestions in [RFC5444] regarding inclusion of a
cryptographic signature in a Message TLV or a Packet TLV can be
applied to this protocol. Failure to verify either form of
cryptographic signature should cause a HELLO message to be rejected
without being processed.
The following simplification of the suggestions for end-to-end
authentication for integrity in [RFC5444] may be applied to HELLO
messages:
o As the Message Header fields <msg-hop-count> and <msg-hop-limit>
are either omitted or will always have the values 0 and 1,
respectively, an end to end cryptographic signature can be
calculated based on the entire HELLO message, including its
unmodified Message Header.
The security mechanisms suggested in [RFC5444] with respect to
confidentiality can be directly applied to this protocol.
18. IANA Considerations
This specification defines one Message Type, which has been allocated
from the "Message Types" registry of [RFC5444], and three Address
Block TLV Types, which have been allocated from the "Address Block
TLV Types" registry of [RFC5444].
18.1. Expert Review: Evaluation Guidelines
For the registries where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444].18.2. Message Types
This specification defines one Message Type, which has been allocated from the 0-223 range of the "Message Types" namespace defined in [RFC5444], as specified in Table 3. +------+-------------------------+ | Type | Description | +------+-------------------------+ | 0 | HELLO : Local signaling | +------+-------------------------+ Table 3: Message Type Assignment18.3. Message-Type-Specific TLV Type Registries
IANA has created a registry for Message-Type-specific Message TLVs for HELLO messages, in accordance with Section 6.2.1 of [RFC5444], and with initial assignments and allocation policies as specified in Table 4. +---------+-------------+-------------------+ | Type | Description | Allocation Policy | +---------+-------------+-------------------+ | 128-223 | Unassigned | Expert Review | +---------+-------------+-------------------+ Table 4: HELLO Message-Type-specific Message TLV Types IANA has created a registry for Message-Type-specific Address Block TLVs for HELLO messages, in accordance with Section 6.2.1 of [RFC5444], and with initial assignments and allocation policies as specified in Table 5. +---------+-------------+-------------------+ | Type | Description | Allocation Policy | +---------+-------------+-------------------+ | 128-223 | Unassigned | Expert Review | +---------+-------------+-------------------+ Table 5: HELLO Message-Type-specific Address Block TLV Types
18.4. Address Block TLV Types
This specification defines three Address Block TLV Types, which have been allocated from the "Address Block TLV Types" namespace defined in [RFC5444]. IANA has made allocations in the 0-127 range for these types. Three new type extension registries have been created, with assignments as specified in Tables 6, 7, and 8. Specifications of these Address Block TLVs are in Section 10.1.1, with Value Constants defined in Section 18.5. +----------+------+-----------+------------------------+------------+ | Name | Type | Type | Description | Allocation | | | | extension | | policy | +----------+------+-----------+------------------------+------------+ | LOCAL_IF | 2 | 0 | Specifies that the | | | | | | network address is | | | | | | associated with this | | | | | | local interface of the | | | | | | sending router | | | | | | (THIS_IF = 0) or | | | | | | another local | | | | | | interface of the | | | | | | sending router | | | | | | (OTHER_IF = 1) | | | LOCAL_IF | 2 | 1-255 | Unassigned | Expert | | | | | | Review | +----------+------+-----------+------------------------+------------+ Table 6: Address Block TLV Type Assignment: LOCAL_IF +-------------+------+-----------+---------------------+------------+ | Name | Type | Type | Description | Allocation | | | | extension | | policy | +-------------+------+-----------+---------------------+------------+ | LINK_STATUS | 3 | 0 | Specifies the | | | | | | status of the link | | | | | | from the indicated | | | | | | network address | | | | | | (LOST = 0, | | | | | | SYMMETRIC = 1, or | | | | | | HEARD = 2) | | | LINK_STATUS | 3 | 1-255 | Unassigned | Expert | | | | | | Review | +-------------+------+-----------+---------------------+------------+ Table 7: Address Block TLV Type Assignment: LINK_STATUS
+--------------+------+-----------+--------------------+------------+ | Name | Type | Type | Description | Allocation | | | | extension | | policy | +--------------+------+-----------+--------------------+------------+ | OTHER_NEIGHB | 4 | 0 | Specifies the | | | | | | status of the | | | | | | relationship with | | | | | | the router that | | | | | | uses the indicated | | | | | | network address on | | | | | | one or more | | | | | | interfaces (LOST = | | | | | | 0, or SYMMETRIC = | | | | | | 1) | | | OTHER_NEIGHB | 4 | 1-255 | Unassigned | Expert | | | | | | Review | +--------------+------+-----------+--------------------+------------+ Table 8: Address Block TLV Type Assignment: OTHER_NEIGHB18.5. LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Values
Note: This information is recorded here for clarity and for use elsewhere in this specification. The information required by IANA is included in the descriptions of the Address Block TLVs allocated in Section 18.4. The Values that the LOCAL_IF Address Block TLV can use are the following: o THIS_IF := 0 o OTHER_IF := 1 The Values that the LINK_STATUS Address Block TLV can use are the following: o LOST := 0 o SYMMETRIC := 1 o HEARD := 2 The Values that the OTHER_NEIGHB Address Block TLV can use are the following: o LOST := 0
o SYMMETRIC := 119. Contributors
This specification is the result of the joint efforts of the following contributors from the OLSRv2 Design Team, listed alphabetically: o Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil> o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr> o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org> o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil> o Christopher Dearlove, BAE Systems ATC, UK, <chris.dearlove@baesystems.com> o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>20. Acknowledgments
The authors would like to acknowledge the team behind OLSRv1, specified in RFC3626 for their contributions. The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews and comments on the specification and its components (listed alphabetically): Alan Cullen (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA), and the entire IETF MANET working group.
21. References
21.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, February 2008. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009. [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 2009. [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols", RFC 5498, March 2009.21.2. Informative References
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, "OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks", RFC 5449, February 2009.
(next page on part 4)
