Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 6130

Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)

Pages: 88
Proposed Standard
Errata
Updated by:  718371887466
Part 3 of 4 – Pages 38 to 62
First   Prev   Next

Top   ToC   RFC6130 - Page 38   prevText

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.)
Top   ToC   RFC6130 - Page 39
   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.
Top   ToC   RFC6130 - Page 40
   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
Top   ToC   RFC6130 - Page 41
      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.
Top   ToC   RFC6130 - Page 42
           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.
Top   ToC   RFC6130 - Page 43
   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:
Top   ToC   RFC6130 - Page 44
                   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
Top   ToC   RFC6130 - Page 45
               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.
Top   ToC   RFC6130 - Page 46
   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.
Top   ToC   RFC6130 - Page 47
   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;
Top   ToC   RFC6130 - Page 48
               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.
Top   ToC   RFC6130 - Page 49

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.
Top   ToC   RFC6130 - Page 50
   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.)
Top   ToC   RFC6130 - Page 51

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_INTERVAL

15.2. Information Validity Time Interface Parameters

o H_HOLD_TIME := 3 x REFRESH_INTERVAL o L_HOLD_TIME := H_HOLD_TIME
Top   ToC   RFC6130 - Page 52

15.3. Information Validity Time Router Parameters

o N_HOLD_TIME := L_HOLD_TIME o I_HOLD_TIME := N_HOLD_TIME

15.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 := false

15.5. Jitter Interface Parameters

o HP_MAXJITTER := HELLO_INTERVAL/4 o HT_MAXJITTER := HP_MAXJITTER

15.6. Constants

o C := 1/1024 second

16. 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
Top   ToC   RFC6130 - Page 53
      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.
Top   ToC   RFC6130 - Page 54
   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.
Top   ToC   RFC6130 - Page 55
   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.
Top   ToC   RFC6130 - Page 56
   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.
Top   ToC   RFC6130 - Page 57
      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].
Top   ToC   RFC6130 - Page 58

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 Assignment

18.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
Top   ToC   RFC6130 - Page 59

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
Top   ToC   RFC6130 - Page 60
   +--------------+------+-----------+--------------------+------------+
   |     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_NEIGHB

18.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
Top   ToC   RFC6130 - Page 61
   o  SYMMETRIC := 1

19. 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.
Top   ToC   RFC6130 - Page 62

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)

Next Section