doc: Add RFC documents

1 files changed, 4931 insertions, 0 deletions

diff --git a/doc/rfc/rfc6130.txt b/doc/rfc/rfc6130.txt
new file mode 100644
index 0000000..553a0b9
--- /dev/null
+++ b/doc/rfc/rfc6130.txt
@@ -0,0 +1,4931 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        T. Clausen
+Request for Comments: 6130                      LIX, Ecole Polytechnique
+Category: Standards Track                                    C. Dearlove
+ISSN: 2070-1721                                          BAE Systems ATC
+                                                                 J. Dean
+                                               Naval Research Laboratory
+                                                              April 2011
+
+
+  Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
+
+Abstract
+
+   This document describes a 1-hop and symmetric 2-hop neighborhood
+   discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6130.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+
+
+
+Clausen, et al.              Standards Track                    [Page 1]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+  1. Introduction .....................................................4
+      1.1. Motivation .................................................5
+   2. Terminology .....................................................6
+   3. Applicability Statement .........................................9
+   4. Protocol Overview and Functioning ..............................10
+      4.1. Routers and Interfaces ....................................11
+      4.2. Information Base Overview .................................12
+           4.2.1. Local Information Base .............................13
+           4.2.2. Interface Information Bases ........................13
+           4.2.3. Neighbor Information Base ..........................14
+      4.3. Signaling Overview ........................................14
+           4.3.1. HELLO Message Generation ...........................15
+           4.3.2. HELLO Message Content ..............................16
+           4.3.3. HELLO Message Processing ...........................17
+      4.4. Link Quality ..............................................17
+   5. Protocol Parameters and Constants ..............................18
+      5.1. Protocol and Port Numbers .................................18
+      5.2. Multicast Address .........................................18
+      5.3. Interface Parameters ......................................18
+           5.3.1. Message Intervals ..................................19
+           5.3.2. Information Validity Times .........................21
+           5.3.3. Link Quality .......................................22
+           5.3.4. Jitter .............................................22
+      5.4. Router Parameters .........................................23
+           5.4.1. Information Validity Time ..........................23
+      5.5. Parameter Change Constraints ..............................23
+      5.6. Constants .................................................24
+   6. Local Information Base .........................................24
+      6.1. Local Interface Set .......................................25
+      6.2. Removed Interface Address Set .............................26
+   7. Interface Information Bases ....................................26
+      7.1. Link Set ..................................................27
+      7.2. 2-Hop Set .................................................28
+   8. Neighbor Information Base ......................................28
+      8.1. Neighbor Set ..............................................28
+      8.2. Lost Neighbor Set .........................................29
+   9. Local Information Base Changes .................................29
+
+
+
+Clausen, et al.              Standards Track                    [Page 2]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+      9.1. Adding an Interface .......................................29
+      9.2. Removing an Interface .....................................30
+      9.3. Adding a Network Address to an Interface ..................30
+      9.4. Removing a Network Address from an Interface ..............31
+   10. Packets and Messages ..........................................32
+      10.1. HELLO Messages ...........................................32
+           10.1.1. Address Blocks ....................................33
+   11. HELLO Message Generation ......................................34
+      11.1. HELLO Message Specification ..............................35
+      11.2. HELLO Message Transmission ...............................37
+           11.2.1. HELLO Message Jitter ..............................37
+   12. HELLO Message Processing ......................................38
+      12.1. Invalid Message ..........................................38
+      12.2. Definitions ..............................................40
+      12.3. Updating the Neighbor Set ................................41
+      12.4. Updating the Lost Neighbor Set ...........................42
+      12.5. Updating the Link Sets ...................................42
+      12.6. Updating the 2-Hop Set ...................................44
+   13. Other Information Base Changes ................................45
+      13.1. Link Tuple Symmetric .....................................46
+      13.2. Link Tuple Not Symmetric .................................47
+      13.3. Link Tuple Heard Timeout .................................48
+   14. Link Quality ..................................................48
+      14.1. Deployment without Link Quality ..........................49
+      14.2. Basic Principles of Link Quality .........................49
+      14.3. When Link Quality Changes ................................50
+      14.4. Updating Link Quality ....................................51
+   15. Proposed Values for Parameters and Constants ..................51
+      15.1. Message Interval Interface Parameters ....................51
+      15.2. Information Validity Time Interface Parameters ...........51
+      15.3. Information Validity Time Router Parameters ..............52
+      15.4. Link Quality Interface Parameters ........................52
+      15.5. Jitter Interface Parameters ..............................52
+      15.6. Constants ................................................52
+   16. Usage with Other Protocols ....................................52
+   17. Security Considerations .......................................54
+      17.1. Invalid HELLO Messages ...................................56
+      17.2. Authentication, Integrity, and Confidentiality
+            Suggestions ..............................................57
+   18. IANA Considerations ...........................................57
+      18.1. Expert Review: Evaluation Guidelines .....................58
+      18.2. Message Types ............................................58
+      18.3. Message-Type-Specific TLV Type Registries ................58
+      18.4. Address Block TLV Types ..................................59
+      18.5. LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Values ...........60
+   19. Contributors ..................................................61
+   20. Acknowledgments ...............................................61
+   21. References ....................................................62
+
+
+
+Clausen, et al.              Standards Track                    [Page 3]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+      21.1. Normative References .....................................62
+      21.2. Informative References ...................................62
+   Appendix A. Address Block TLV Combinations ........................63
+   Appendix B. Constraints ...........................................64
+   Appendix C. HELLO Message Example .................................66
+   Appendix D. Flow and Congestion Control ...........................69
+   Appendix E. Interval and Timer Illustrations ......................70
+      E.1.  HELLO Message Generation Timing ..........................70
+      E.2.  HELLO Message Processing Timing ..........................76
+      E.3.  Other HELLO Message Timing ...............................77
+   Appendix F.  Topology Pictures ....................................79
+      F.1.  Example 1: Standard Single Interface Topology ............79
+      F.2.  Example 2: Dual Addressed Interface on 1-Hop Neighbor ....80
+      F.3.  Example 3: Dual Addressed Interface on 2-Hop Neighbor ....81
+      F.4.  Example 4: Dual Addressed Interfaces .....................81
+      F.5.  Example 5: Dual Interface on 2-Hop Neighbor ..............82
+      F.6.  Example 6: Dual interface on 1-Hop Neighbor ..............82
+      F.7.  Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors ...83
+      F.8.  Example 8: Dual Interface Locally and on 1-Hop Neighbor ..84
+      F.9.  Example 9: Dual Interface on All Routers .................85
+      F.10. Example 10: Dual Addressed Dual Interfaces on All
+                        Routers ......................................86
+      F.11. Example 11: Single Addressed Dual Interface Locally ......87
+
+1.  Introduction
+
+   This document describes a neighborhood discovery protocol (NHDP) for
+   a mobile ad hoc network (MANET) [RFC2501].  This protocol uses a
+   local exchange of HELLO messages so that each router can determine
+   the presence of, and connectivity to, its 1-hop and symmetric 2-hop
+   neighbors.  Messages are defined and sent in packets according to the
+   specification [RFC5444].
+
+   1-hop neighborhood information is recorded for use by MANET routing
+   protocols to determine direct (1-hop) connectivity to neighboring
+   routers. 2-hop symmetric neighborhood information is recorded so as
+   to enable MANET routing protocols to employ flooding reduction
+   techniques, e.g., to select reduced relay sets for efficient network-
+   wide traffic dissemination.
+
+   1-hop and symmetric 2-hop neighborhood information is recorded in the
+   form of Information Bases.  These are available for use by other
+   protocols, such as MANET routing protocols, that require information
+   regarding the local network connectivity.  This protocol is designed
+   to maintain the information in these Information Bases even in the
+   presence of a dynamic network topology and wireless communication
+   channel characteristics.
+
+
+
+
+Clausen, et al.              Standards Track                    [Page 4]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   This protocol makes no assumptions about the underlying link layer,
+   other than support of local broadcast or multicast for communication
+   to 1-hop neighbor routers.  Link-layer information may be used if
+   available and applicable.
+
+   This protocol is based on the neighborhood discovery process
+   contained in the Optimized Link State Routing (OLSR) Protocol
+   [RFC3626].
+
+1.1.  Motivation
+
+   MANETs differ from more traditional wired and infrastructure-based
+   wireless networks due to their envisioned applicability over more
+   challenging communication channels (e.g., wireless, lossy, broadcast
+   channels with moderate and shared bandwidth, hidden and exposed
+   terminals, and interference from other network devices and the
+   environment) and in more challenging topological conditions (e.g.,
+   rapid and unpredictable mobility, dynamic and non-predetermined
+   network membership).
+
+   Due to the properties of wireless transmissions, communication
+   between two neighboring routers may not be bi-directional; even if
+   router A is able to receive packets from router B, the converse is
+   not guaranteed to be true.  Furthermore, because of the localized
+   nature of wireless broadcast communication, neighboring routers
+   within the same communications channel may have different sets of
+   neighbors.  That is, when using the same communication channel, even
+   if router A is able to exchange packets with router B, and router B
+   is able to exchange packets with router C, this does not guarantee
+   that router A and router C can exchange packets directly.
+
+   Each router in a MANET may use more than one communication channel.
+   In particular, between the same pair of routers, more than one
+   distinct communication channel may exist, each with different
+   properties.  This may, for example, be the case where MANET routers
+   are equipped with multiple distinct wireless interfaces, operating at
+   different frequencies.
+
+   For use by MANET routing protocols, as well as for establishing a
+   router's neighbors, a router may also need to determine whether each
+   communication channel with that neighbor is bi-directional.
+
+   The set of neighbor routers of a given MANET router may be
+   continuously changing, often due to router mobility or a changing
+   physical environment in which the MANET is located.  There is
+   typically no information from lower layers that would enable an IP
+   routing protocol to detect and, as appropriate, react to such
+   changes.  Such changes can often take place on a short timescale,
+
+
+
+Clausen, et al.              Standards Track                    [Page 5]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   such as of the order of seconds, requiring MANET routing protocols to
+   act rapidly to ensure suitable convergence properties.
+
+   MANET routing protocols, for example [RFC3626] and [RFC5449], often
+   employ relay set reductions in order to conserve network capacity
+   when maintaining network-wide topological information, with
+   calculation of these reduced relay sets employing up to two hop
+   information.
+
+   The neighborhood discovery protocol specified in this document
+   provides continued tracking of neighborhood changes, link bi-
+   directionality, and local topological information up to two hops.
+   Combined, this allows a MANET routing protocol access to information
+   describing link establishment/disappearance and provides the
+   necessary topological information for reduced relay set selection and
+   other purposes.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+   All terms introduced in [RFC5444], including "packet", "message",
+   "Address Block", "TLV Block", "TLV", "address", "address prefix", and
+   "address object" are to be interpreted as described therein.
+
+   Additionally, this document uses the following terminology:
+
+   Network Address:
+      An address plus an associated prefix length.  This may be an
+      address with an associated maximum prefix length or an address
+      prefix including a prefix length.  A network address thus
+      represents a range of addresses.
+
+   Router:
+      A MANET router that implements this neighborhood discovery
+      protocol.
+
+   Interface:
+      A router's attachment to a communications medium.  An interface is
+      assigned one or more addresses.
+
+   MANET interface:
+      An interface participating in a MANET and using this neighborhood
+      discovery protocol.  A router may have several MANET interfaces.
+
+
+
+
+Clausen, et al.              Standards Track                    [Page 6]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   Heard:
+      A MANET interface of router X is considered heard on a MANET
+      interface of a router Y if the latter can receive control
+      messages, according to this specification, from the former.
+
+   Link:
+      A link between two MANET interfaces exists if either can be heard
+      by the other.
+
+   Symmetric link:
+      A symmetric link between two MANET interfaces exists if both can
+      be heard by the other.
+
+   1-hop neighbor:
+      A router X is a 1-hop neighbor of a router Y if a MANET interface
+      of router X is heard by a MANET interface of router Y.
+
+   Symmetric 1-hop neighbor:
+      A router X is a symmetric 1-hop neighbor of a router Y if a
+      symmetric link exists between a MANET interface on router X and a
+      MANET interface on router Y.
+
+   2-hop neighbor:
+      A router X is a 2-hop neighbor of a router Y if router X is a
+      1-hop neighbor of a 1-hop neighbor of router Y, but is not router
+      Y itself.
+
+   Symmetric 2-hop neighbor:
+      A router X is a symmetric 2-hop neighbor of a router Y if router X
+      is a symmetric 1-hop neighbor of a symmetric 1-hop neighbor of
+      router Y, but is not router Y itself.
+
+   1-hop neighborhood:
+      The 1-hop neighborhood of a router X is the set of the 1-hop
+      neighbors of router X.
+
+   Symmetric 1-hop neighborhood:
+      The symmetric 1-hop neighborhood of a router X is the set of the
+      symmetric 1-hop neighbors of router X.
+
+   2-hop neighborhood:
+      The 2-hop neighborhood of a router X is the set of the 2-hop
+      neighbors of router X. (This may include routers in the 1-hop
+      neighborhood of router X.)
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                    [Page 7]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   Symmetric 2-hop neighborhood:
+      The symmetric 2-hop neighborhood of a router X is the set of the
+      symmetric 2-hop neighbors of router X. (This may include routers
+      in the 1-hop neighborhood, or even in the symmetric 1-hop
+      neighborhood, of router X.)
+
+   Constant:
+      A numerical value that MUST be the same for all MANET interfaces
+      of all routers in the MANET, at all times.
+
+   Interface parameter:
+      A boolean or numerical value, specified separately for each MANET
+      interface of each router.  A router MAY change interface parameter
+      values at any time, subject to some constraints.
+
+   Router parameter:
+      A boolean or numerical value, specified for each router, and not
+      specific to an interface.  A router MAY change router parameter
+      values at any time, subject to some constraints.
+
+   Information Base:
+      A collection of information maintained by this protocol and which
+      is to be made available to MANET routing protocols.  An
+      Information Base may be associated with a MANET interface or with
+      a router.
+
+   Furthermore, this document uses the following notational conventions:
+
+   X contains y, or y is contained in X
+      An unordered list membership operator.  X is an unordered list and
+      y is an element.  "X contains y" or "y is contained in X" returns
+      true if the unordered list X includes the element y, and returns
+      false otherwise.
+
+   X contains Y, or Y is contained in X
+      An unordered list inclusion operator.  X and Y are both unordered
+      lists.  "X contains Y" or "Y is contained in X" returns true if
+      the unordered list X contains all elements y which are contained
+      in Y, and returns false otherwise.
+
+   A overlaps B
+      If A and B are network addresses, and the range of addresses
+      represented by A and the range of addresses represented by B both
+      contain at least one common address.  (This is only possible if
+      one range is a sub-range of the other.)
+
+
+
+
+
+
+Clausen, et al.              Standards Track                    [Page 8]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   a := b
+      An assignment operator, whereby the left side (a) is assigned the
+      value of the right side (b). a and b may be values, network
+      addresses, or unordered lists (they must be of the same type).
+
+   c = d
+      A comparison operator, returning true if the value of the left
+      side (c) is equal to the value of the right side (d). c and d may
+      be values, network addresses, or unordered lists (they must be of
+      the same type).  If c and d are unordered lists, then they are
+      considered to be equal if c contains d and d contains c (i.e.,
+      they contain the same set of elements, regardless of the order in
+      which they are recorded in the lists).  If c and d are network
+      addresses, they are considered equal only if both addresses and
+      prefix lengths are equal (i.e., they represent the same).
+
+   e != f
+      A comparison operator, returning not (e = f), i.e., returning true
+      where (e = f) would have returned false, and returning false where
+      (e = f) would have returned true.
+
+3.  Applicability Statement
+
+   This protocol:
+
+   o  Is applicable to networks, especially wireless networks, in which
+      unknown neighbors can be reached by local broadcast or multicast
+      packets.
+
+   o  Is designed to work in networks with a dynamic topology, and in
+      which messages may be lost, such as due to collisions in wireless
+      networks.
+
+   o  Supports routers that each have one or more participating MANET
+      interfaces.  The set of a router's interfaces may change over
+      time.  Each interface may have one or more associated network
+      addresses, and these may also be dynamically changing.
+
+   o  Provides each router with current local topology information up to
+      two hops away, and makes this local topology information available
+      to MANET routing protocols in Information Bases.
+
+   o  Uses the packet and message formats specified in [RFC5444].  This
+      includes the definition of a HELLO Message Type, used for
+      signaling local topology information.
+
+   o  Allows "external" and "internal" extensibility as enabled by
+      [RFC5444].
+
+
+
+Clausen, et al.              Standards Track                    [Page 9]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   o  May interact with, and be extended by, other protocols, such as
+      MANET routing protocols, see Section 16.
+
+   o  Can use relevant link-layer information if it is available.
+
+   o  Is designed to work in a completely distributed manner, and does
+      not depend on any central entity.
+
+4.  Protocol Overview and Functioning
+
+   The objective of this protocol is, for each router:
+
+   o  To identify 1-hop neighbors and symmetric 1-hop neighbors of this
+      router.
+
+   o  To find the interface network addresses of the router's symmetric
+      2-hop neighbors.
+
+   o  To record this information in Information Bases and thus make this
+      information available to other protocols that use this
+      neighborhood discovery protocol.
+
+   o  To be available for use by other protocols, which MAY extend the
+      information in these Information Bases, including adding new Sets
+      to Information Bases, new elements to protocol Tuples and new TLVs
+      to be included in outgoing HELLO messages and processed when in
+      incoming HELLO messages.
+
+   These objectives are achieved using local (1-hop) signaling that:
+
+   o  Advertises the presence of a router and its interface network
+      addresses.
+
+   o  Discovers links from neighboring routers.
+
+   o  Performs bi-directionality checks on the discovered links.
+
+   o  Advertises discovered links, and whether each is symmetric, to its
+      1-hop neighbors, and hence discovers symmetric 2-hop neighbors.
+
+   This specification defines, in turn:
+
+   o  Parameters and constants used by the protocol.  Parameters used by
+      this protocol may, where appropriate, be specific to a given MANET
+      interface or to a MANET router.  This protocol allows all
+      parameters to be changed dynamically, and to be set independently
+      for each MANET router or MANET interface, as appropriate.
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 10]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   o  The Information Bases describing local interfaces, discovered
+      links and their status, current and former 1-hop neighbors, and
+      symmetric 2-hop neighbors.
+
+   o  The format of the HELLO message that is used for local signaling.
+
+   o  The generation of HELLO messages from some of the information in
+      the Information Bases.
+
+   o  The updating of the Information Bases according to received HELLO
+      messages and other events.
+
+   o  The response to other events, such as the expiration of
+      information in the Information Bases.
+
+4.1.  Routers and Interfaces
+
+   In order for a router to participate in a MANET, it MUST have at
+   least one, and possibly more, MANET interfaces.
+
+   Each MANET interface:
+
+   o  Is configured with one or more network addresses.  Each address in
+      the range of addresses represented by that network address MUST
+      satisfy the following properties:
+
+      o  It MUST be unique to this router, i.e., it MUST NOT be assigned
+         to any interface of any other router.
+
+      o  If assigned to other MANET interfaces, on the same router,
+         these MANET interfaces MUST be isolated, i.e., addresses may
+         only be assigned to different interfaces on the same router if
+         no MANET interface on another router can communicate with both.
+         For example, interfaces using distinct radio "channels" MAY be
+         assigned the same address.
+
+   o  Has a set of interface parameters, defining the behavior of this
+      MANET interface.  Each MANET interface MAY be individually
+      parameterized.
+
+   o  Has an Interface Information Base, recording information regarding
+      links to this MANET interface and symmetric 2-hop neighbors that
+      can be reached through such links.
+
+   o  Generates and processes HELLO messages.
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 11]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   In addition to a set of MANET interfaces as described above, each
+   router has:
+
+   o  A Local Information Base, containing the network addresses of the
+      interfaces (MANET and non-MANET) of this router.  The contents of
+      this Information Base are not changed by signaling.
+
+   o  A Neighbor Information Base, recording information regarding
+      current and recently lost 1-hop neighbors of this router.
+
+   A router may have both MANET interfaces and non-MANET interfaces.
+   Interfaces of both of these types are recorded in a router's Local
+   Information Base, which is used, but not updated, by the signaling of
+   this protocol.
+
+4.2.  Information Base Overview
+
+   Each router maintains protocol state using Information Bases,
+   described in the following sections.  Each Information Base consists
+   of a number of Protocol Sets.  Each Protocol Set contains a number of
+   Protocol Tuples.
+
+   An implementation of this protocol MAY maintain this information in
+   the indicated form, or in any other organization that offers access
+   to this information.  In particular, note that it is not necessary to
+   remove Protocol Tuples from Protocol Sets at the exact time
+   indicated, only to behave as if the Protocol Tuples were removed at
+   that time.
+
+   Information in the Local Information Base is defined locally and
+   included in HELLO messages.  Information in the Interface Information
+   Base and the Neighbor Information Base is determined from received
+   HELLO messages; some of this information may also be included in
+   transmitted HELLO messages.  Such information has a limited duration
+   in which it is considered valid.  This duration is determined from
+   the VALIDITY_TIME TLV in the HELLO message in which the information
+   is received, which in turn is set by the router that originated the
+   HELLO message, using its corresponding interface parameter
+   H_HOLD_TIME.
+
+   Appendix E illustrates the relationship between message reception,
+   included VALIDITY_TIME TLVs, and the duration for which information
+   received in a HELLO message is considered valid.  Appendix F
+   illustrates some example topologies and how they correspond to
+   information in the Information Bases.
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 12]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+4.2.1.  Local Information Base
+
+   Each router maintains a Local Information Base, which contains the
+   router's local configuration information, specifically:
+
+   o  The Local Interface Set, which consists of Local Interface Tuples,
+      each of which represents an interface (MANET or non-MANET) of the
+      router.
+
+   o  The Removed Interface Address Set, which consists of Removed
+      Interface Address Tuples, each of which records a recently used
+      network address of an interface (MANET or non-MANET) of the
+      router.
+
+   The Local Interface Set is used for generating HELLO messages,
+   specifically for determining which interface network addresses are to
+   be included and identified as local interfaces.  The Removed
+   Interface Address Set is used to avoid incorrectly recording a
+   formerly used network address as a symmetric 2-hop neighbor's network
+   address.
+
+   The Local Information Base is used for generating signaling, but is
+   not itself updated by signaling specified in this document.  Updates
+   to the Local Information Base are due to changes of the router
+   configuration, and may be allowed to trigger signaling.
+
+4.2.2.  Interface Information Bases
+
+   Each router maintains, for each of its MANET interfaces, an Interface
+   Information Base, which contains 1-hop neighborhood and symmetric
+   2-hop neighborhood information collected from this MANET interface,
+   specifically:
+
+   o  A Link Set, which records information about current and recently
+      lost links between this MANET interface and MANET interfaces of
+      1-hop neighbors.  The Link Set consists of Link Tuples, each of
+      which contains information about a single link.  Link quality
+      information (see Section 14), when used, is recorded in Link
+      Tuples.
+
+   o  A 2-Hop Set, which records the existence of symmetric links
+      between symmetric 1-hop neighbors of this MANET interface and
+      other routers (symmetric 2-hop neighbors).  The 2-Hop Set consists
+      of 2-Hop Tuples, each of which records a network address of a
+      symmetric 2-hop neighbor, and all network addresses of the
+      corresponding symmetric 1-hop neighbor.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 13]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   The Link Set for a MANET interface is used for generating HELLO
+   messages.  Specifically, the Link Set information is included to both
+   allow other routers to identify symmetric links and to populate the
+   2-Hop Set.  Recently lost links are recorded in the Link Set for a
+   MANET interface so that they can be advertised in HELLO messages,
+   accelerating their removal from relevant 1-hop neighbors' Link Sets.
+
+   The Link Set for a MANET interface is itself updated on receiving a
+   HELLO message, including recording symmetric links as indicated
+   above.  The 2-Hop Set for a MANET interface is updated as indicated
+   above, and is not itself used in generating HELLO messages.
+
+4.2.3.  Neighbor Information Base
+
+   Each router maintains a Neighbor Information Base, which contains
+   collected information about current and recently lost 1-hop
+   neighbors, specifically:
+
+   o  The Neighbor Set consists of Neighbor Tuples, each of which
+      records all network addresses of a single 1-hop neighbor.
+      Neighbor Tuples are maintained as long as there are corresponding
+      Link Tuples.
+
+   o  The Lost Neighbor Set consists of Lost Neighbor Tuples, each of
+      which records a network address of a recently lost symmetric 1-hop
+      neighbor.
+
+   The Neighbor Set associates all network addresses of each 1-hop
+   neighbor.  These network addresses may be included when generating a
+   HELLO message, so that other symmetric 1-hop neighbors can record
+   this information in a 2-Hop Set.  The Neighbor Set can be updated on
+   receiving a HELLO message.
+
+   The Lost Neighbor Set is used to determine which network addresses
+   are to be included in a HELLO message as being lost (of a recently
+   symmetric 1-hop neighbor).  The Lost Neighbor Set can itself be
+   updated on receiving a HELLO message.
+
+4.3.  Signaling Overview
+
+   This protocol contains a signaling mechanism for maintaining the
+   Interface Information Bases and the Neighbor Information Base.  If
+   information from the link layer, or any other source, is available
+   and appropriate, it may also be used to update these Information
+   Bases.  Such updates are subject to the constraints specified in
+   Appendix B.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 14]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   Signaling consists of a single type of message, known as a HELLO
+   message.  Each router generates HELLO messages on each of its MANET
+   interfaces.  HELLO messages are generated independently on each MANET
+   interface of a MANET router; the content of a given HELLO message
+   depends on the MANET interface for which it has been generated.
+
+   Each HELLO message:
+
+   o  Identifies, as far as is required, the MANET interface for which
+      it is generated and transmitted; this allows recipients of that
+      HELLO message to identify that MANET interface from among those it
+      may hear.
+
+   o  Reports the network addresses of other interfaces (MANET and non-
+      MANET) of the router; this allows recipients of that HELLO message
+      to associate a set of network addresses with a single 1-hop
+      neighbor.
+
+   o  Includes 1-hop neighbor information from the Information Bases;
+      this allows detection of local symmetric links, and symmetric
+      2-hop neighbors.
+
+   HELLO message generation, and the validity of the information
+   recorded as a consequence of processing a HELLO message, is affected
+   by timers and validity information included in HELLO messages through
+   TLVs.  The relationship between message timers and intervals is
+   illustrated in Appendix E.
+
+4.3.1.  HELLO Message Generation
+
+   HELLO messages are generated by a router for each of its MANET
+   interfaces, and MAY be sent:
+
+   o  Proactively, at a regular interval, known as HELLO_INTERVAL.
+      HELLO_INTERVAL may be fixed, or may be dynamic.  For example,
+      HELLO_INTERVAL may be backed off due to congestion or network
+      stability.
+
+   o  As a response to a change in the router itself, or its 1-hop
+      neighborhood, for example, on first becoming active or in response
+      to a new, lost, or changed status link.
+
+   o  In a combination of these proactive and responsive mechanisms.
+
+   Jittering of HELLO message generation and transmission SHOULD be used
+   as described in Section 11.2, unless the medium access control
+   mechanism in use prevents any simultaneous transmissions by
+   potentially interfering routers.
+
+
+
+Clausen, et al.              Standards Track                   [Page 15]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   HELLO messages MAY be scheduled independently for each MANET
+   interface, or, interface parameters permitting, using the same
+   schedule for all MANET interfaces of a router.
+
+4.3.2.  HELLO Message Content
+
+   The content of a HELLO message MUST satisfy the following:
+
+   o  A HELLO message MUST contain all of the network addresses in the
+      Local Interface Set of the router on which the HELLO message is
+      being generated.  This includes:
+
+      o  At least one network address of each MANET interface of the
+         router.
+
+      o  Network addresses that include all source addresses of any IP
+         datagrams sent by the router on any MANET interface.
+
+      o  All other network addresses of the router that are to be made
+         known to any other router for any reason.
+
+   o  For each MANET interface, within every time interval equal to the
+      corresponding REFRESH_INTERVAL, sent HELLO messages MUST
+      collectively include all of the relevant information in the
+      corresponding Link Set and the Neighbor Information Base.  Note
+      that when determining whether to include information in a HELLO
+      message, the sender MUST consider all times up to the latest time
+      when it may send its next HELLO message on this MANET interface.
+
+   o  For each MANET interface, within every time interval equal to the
+      corresponding REFRESH_INTERVAL, sent HELLO messages MUST
+      collectively include all of the relevant information in the
+      corresponding Link Set and the Neighbor Information Base.
+
+   o  When determining whether to include a given piece of neighbor
+      information in a HELLO message, it is not sufficient to consider
+      whether that information has been sent in the interval of length
+      REFRESH_INTERVAL up to the current time.  Instead, the router MUST
+      consider the interval of length REFRESH_INTERVAL that will end at
+      the latest possible time at which the next HELLO message will be
+      sent on this MANET interface.  (Normally, this will be
+      HELLO_INTERVAL past the current time, but MAY be earlier if this
+      router elects to divide its neighbor information among more than
+      one HELLO message in order to reduce the size of its HELLO
+      messages.)  All neighbor information MUST be sent in this
+      interval, i.e., the router MUST ensure that this HELLO message
+      includes all neighbor information that has not already been
+      included in any HELLO messages sent since the start of this
+
+
+
+Clausen, et al.              Standards Track                   [Page 16]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+      interval (normally, the current time - (REFRESH_INTERVAL -
+      HELLO_INTERVAL)).
+
+   o  A HELLO message MUST include exactly one VALIDITY_TIME Message
+      TLV, as specified in [RFC5497], that indicates the length of time
+      for which the message content is to be considered valid, and is
+      therefore to be included in the receiving router's Interface
+      Information Base.
+
+   o  A periodically generated HELLO message SHOULD include exactly one
+      INTERVAL_TIME Message TLV, as specified in [RFC5497], that
+      indicates the current value of HELLO_INTERVAL for that MANET
+      interface, i.e., the period within which a further HELLO message
+      is guaranteed to be sent on that MANET interface.
+
+4.3.3.  HELLO Message Processing
+
+   HELLO messages received by a router are used to update the Interface
+   Information Base for the MANET interface over which that HELLO
+   message was received, as well as the Neighbor Information Base of the
+   router.  Specifically:
+
+   o  The router ensures that there is a single Neighbor Tuple
+      corresponding to the originator of that HELLO message.
+
+   o  The router ensures that there is a Link Tuple, with appropriate
+      status (heard or symmetric) and advertised duration, corresponding
+      to the link between the MANET interfaces on which that HELLO
+      message was sent and received.  One or more Lost Neighbor Tuples
+      may be created if the HELLO message reports that the link was
+      lost.
+
+   o  If the link between the MANET interfaces on which the HELLO
+      message was sent and received is symmetric, then the router
+      ensures that there are the appropriate 2-Hop Tuples, with
+      advertised duration.
+
+   The processing defined in this specification handles any unexpected
+   and erroneous information in a HELLO message, maintaining the
+   constraints on Information Base contents specified in Appendix B.
+
+4.4.  Link Quality
+
+   Some links in a MANET may be marginal, e.g., due to adverse wireless
+   propagation.  In order to avoid using such marginal links, a link
+   quality value is recorded in each Link Tuple.  A MANET router
+   considers links for which an insufficient link quality is recorded as
+   lost.  Modifying the recorded link quality in a Link Tuple is
+
+
+
+Clausen, et al.              Standards Track                   [Page 17]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   OPTIONAL.  If link quality is not to be modified, it MUST be set to
+   indicate an always usable quality link.
+
+   Note that link quality is a "link admittance" mechanism, allowing a
+   router to determine that a given link is too unstable to even
+   consider for use.  It is specifically not a link metric nor is it a
+   substitute for one.
+
+   Link quality information is only used locally and is not used in
+   signaling.  Routers may interoperate whether they are using the same,
+   different, or no link quality information.  Link quality information
+   is thus not equivalent to a link metric.
+
+   Link quality information is defined in this specification as a
+   normalized, dimensionless value in the interval zero to one,
+   inclusive, where the greater the value, the better the link quality.
+   See Section 14 for further details.
+
+5.  Protocol Parameters and Constants
+
+   The parameters and constants used in this specification are described
+   in this section.
+
+5.1.  Protocol and Port Numbers
+
+   This protocol specifies HELLO messages, which are included in packets
+   as defined by [RFC5444].  These packets may be sent using either the
+   "manet" protocol number or the "manet" well-known UDP port number, as
+   specified in [RFC5498].
+
+5.2.  Multicast Address
+
+   This protocol specifies HELLO messages, which are included in packets
+   as defined by [RFC5444].  These packets may be locally transmitted
+   using the link-local multicast address "LL-MANET-Routers", as
+   specified in [RFC5498].
+
+5.3.  Interface Parameters
+
+   The interface parameters used by this specification may be classified
+   into the following four categories:
+
+   o  Message intervals
+
+   o  Information validity times
+
+   o  Link quality
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 18]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   o  Jitter
+
+   These are detailed in the following sections.
+
+   Different MANET interfaces (on the same or on different routers) MAY
+   employ different interface parameter values and MAY change their
+   interface parameter values dynamically, subject to the constraints
+   given in this section.  A particular case is where all MANET
+   interfaces on all MANET routers within a given MANET employ the same
+   set of interface parameter values.
+
+5.3.1.  Message Intervals
+
+   HELLO messages serve two principal functions:
+
+   o  To advertise network addresses of this router's interface to its
+      1-hop neighbors.  The frequency of these advertisements is
+      regulated by the interface parameters HELLO_INTERVAL and
+      HELLO_MIN_INTERVAL.
+
+   o  To advertise this router's knowledge of each of its 1-hop
+      neighbors.  The frequency of the advertisement of each such
+      neighbor is regulated by the interface parameter REFRESH_INTERVAL.
+
+   Specifically, these parameters are as follows:
+
+   HELLO_INTERVAL:
+      The maximum time between the transmission of two successive HELLO
+      messages on this MANET interface.  If using periodic transmission
+      of HELLO messages, these SHOULD be at a separation of
+      HELLO_INTERVAL, possibly modified by jitter as specified in
+      [RFC5148].
+
+   HELLO_MIN_INTERVAL:
+      The minimum interval between transmission of two successive HELLO
+      messages on this MANET interface.  (This minimum interval MAY be
+      modified by jitter, as defined in [RFC5148].)
+
+   REFRESH_INTERVAL:
+      The maximum interval between advertisements, in a HELLO message on
+      this MANET interface, of each 1-hop neighbor network address and
+      its status.  In all intervals of length REFRESH_INTERVAL, a router
+      MUST include each 1-hop neighbor network address and its status in
+      at least one HELLO message on this MANET interface.  (This may be
+      in the same or in different HELLO messages.)
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 19]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   REFRESH_INTERVAL thus represents the frequency at which a piece of
+   information, as received in HELLO messages, can be expected to be
+   refreshed.  Thus, the REFRESH_INTERVAL is used as a basis for
+   determining when such information expires in receiving routers (see
+   Section 5.3.2).  HELLO_INTERVAL represents the frequency of HELLO
+   message emissions.  Logically, HELLO_INTERVAL cannot be greater than
+   the REFRESH_INTERVAL; otherwise, information cannot be refreshed in a
+   timely manner.
+
+   HELLO messages can, however, be sent with a higher frequency.  A
+   possible use for sending HELLO messages at such a higher frequency
+   includes sending partial HELLO messages (e.g., accommodating
+   constraints on packet sizes from the underlying medium) refreshing
+   only part of the information in each HELLO message.  Another use is
+   for a router to send "empty HELLO messages", advertising its own
+   presence frequently in smaller HELLO messages (e.g., in case HELLO
+   message exchange success rates are used for link quality estimation,
+   or to enable rapid detection by new routers in the neighborhood) in
+   between HELLO messages refreshing neighbor information in other
+   routers.
+
+   The following constraints apply to these interface parameters:
+
+   o  HELLO_INTERVAL > 0
+
+   o  HELLO_MIN_INTERVAL >= 0
+
+   o  HELLO_INTERVAL >= HELLO_MIN_INTERVAL
+
+   o  REFRESH_INTERVAL >= HELLO_INTERVAL
+
+   o  If an INTERVAL_TIME Message TLV as defined in [RFC5497] is
+      included in a HELLO message, then HELLO_INTERVAL MUST be
+      representable as described in [RFC5497].
+
+   If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute
+   its neighbor advertisements between HELLO messages in any manner,
+   subject to the constraints above.
+
+   In the absence of any changes to the local neighborhood, a router
+   will send a HELLO message on a MANET interface after an (possibly
+   jittered) interval of length HELLO_INTERVAL.  For a router to employ
+   this protocol in a purely responsive manner on a MANET interface,
+   i.e., for the router to only send HELLO messages on that MANET
+   interface as a response to external events, HELLO_INTERVAL (and hence
+   also REFRESH_INTERVAL) SHOULD be set sufficiently large, i.e., such
+   that a responsive HELLO message is always expected with a shorter
+   period than this value.
+
+
+
+Clausen, et al.              Standards Track                   [Page 20]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   If a router has more than one MANET interface, then, even if the
+   router configures different values of HELLO_INTERVAL on each MANET
+   interface, the router SHOULD configure the same value of
+   HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO
+   messages may be sent.  (This ensures that changes observed on one
+   MANET interface are reported on other MANET interfaces, so that 1-hop
+   neighbors connected to the latter can maintain up-to-date 2-hop
+   neighborhood information.)
+
+5.3.2.  Information Validity Times
+
+   The following interface parameters manage the validity time of link
+   information:
+
+   L_HOLD_TIME:
+      The period of advertisement, on this MANET interface, of former
+      1-hop neighbor network addresses as lost in HELLO messages,
+      allowing recipients of these HELLO messages to accelerate removal
+      of this information from their Link Sets.  L_HOLD_TIME MAY be set
+      to zero, if accelerated information removal is not required.
+
+   H_HOLD_TIME:
+      Used as the Value in the VALIDITY_TIME Message TLV included in all
+      HELLO messages on this MANET interface.  It is then used by each
+      router receiving such a HELLO message to indicate the validity of
+      the information taken from that HELLO message and recorded in the
+      receiving router's Information Bases.
+
+   Note that as each item of neighbor information is included in HELLO
+   messages within an interval of length REFRESH_INTERVAL, constraints
+   on H_HOLD_TIME are based on REFRESH_INTERVAL, not on HELLO_INTERVAL.
+
+   The following constraints apply to these interface parameters:
+
+   o  L_HOLD_TIME >= 0
+
+   o  H_HOLD_TIME >= REFRESH_INTERVAL
+
+   o  If HELLO messages can be lost, then both parameters SHOULD be
+      significantly greater than REFRESH_INTERVAL.
+
+   o  H_HOLD_TIME MUST be representable as described in [RFC5497].
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 21]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+5.3.3.  Link Quality
+
+   The following interface parameters manage the usage of link quality
+   (see Section 14):
+
+   HYST_ACCEPT:
+      The link quality threshold at or above which a link becomes
+      usable, if it was not already so.
+
+   HYST_REJECT:
+      The link quality threshold below which a link becomes unusable, if
+      it was not already so.
+
+   INITIAL_QUALITY:
+      The initial quality of a newly identified link.
+
+   INITIAL_PENDING:
+      If true, then a newly identified link is considered pending, and
+      is not usable until the link quality has reached or exceeded the
+      HYST_ACCEPT threshold.
+
+   The following constraints apply to these interface parameters:
+
+   o  0 <= HYST_REJECT <= HYST_ACCEPT <= 1
+
+   o  0 <= INITIAL_QUALITY <= 1.
+
+   o  If link quality is not updated, then INITIAL_QUALITY >=
+      HYST_ACCEPT.
+
+   o  If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING := false.
+
+   o  If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING := true.
+
+5.3.4.  Jitter
+
+   If jitter, as defined in [RFC5148], is used, then these parameters
+   are as follows:
+
+   HP_MAXJITTER:
+      Represents the value of MAXJITTER used in [RFC5148] for
+      periodically generated HELLO messages on this MANET interface.
+
+   HT_MAXJITTER:
+      Represents the value of MAXJITTER used in [RFC5148] for externally
+      triggered HELLO messages on this MANET interface.
+
+   For constraints on these interface parameters, see [RFC5148].
+
+
+
+Clausen, et al.              Standards Track                   [Page 22]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+5.4.  Router Parameters
+
+   The two router parameters defined by this specification are in the
+   category of information validity time.
+
+5.4.1.  Information Validity Time
+
+   The following router parameter manages the validity time of lost
+   symmetric 1-hop neighbor information:
+
+   N_HOLD_TIME:
+      Used as the period during which former 1-hop neighbor network
+      addresses are advertised as lost in HELLO messages, allowing
+      recipients of these HELLO messages to accelerate removal of this
+      information from their 2-Hop Sets.  N_HOLD_TIME MAY be set to
+      zero, if accelerated information removal is not required.
+
+   I_HOLD_TIME:
+      The period for which a recently used local interface network
+      address is recorded.
+
+   The following constraints apply to these router parameters:
+
+   o  N_HOLD_TIME >= 0
+
+   o  I_HOLD_TIME >= 0
+
+5.5.  Parameter Change Constraints
+
+   If protocol parameters are changed dynamically, the constraints in
+   this section apply.
+
+   HELLO_INTERVAL
+
+      o  If the HELLO_INTERVAL for a MANET interface increases, then the
+         next HELLO message on this MANET interface MUST be generated
+         according to the previous, shorter, HELLO_INTERVAL.  A number
+         of subsequent HELLO messages MAY be generated according to the
+         previous, shorter, HELLO_INTERVAL (but MUST include times
+         according to current parameters).  This ensures that "promises"
+         as to timely transmission of a future HELLO message are kept
+         until these previous promises have expired.
+
+      o  If the HELLO_INTERVAL for a MANET interface decreases, then the
+         following HELLO messages on this MANET interface MUST be
+         generated according to this current, shorter, HELLO_INTERVAL.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 23]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   REFRESH_INTERVAL
+
+      o  If the REFRESH_INTERVAL for a MANET interface increases, then
+         the content of subsequent HELLO messages must be organized such
+         that the specification of the old value of REFRESH_INTERVAL is
+         satisfied for a further period equal to the old value of
+         REFRESH_INTERVAL.
+
+      o  If the REFRESH_INTERVAL for a MANET interface decreases, then
+         it MAY be necessary to reschedule HELLO message generation on
+         that MANET interface, in order for the specification of
+         REFRESH_INTERVAL is satisfied from the time of change.
+
+   HYST_ACCEPT and HYST_REJECT
+
+      o  If HYST_ACCEPT or HYST_REJECT changes, then the appropriate
+         actions for link quality change, as specified in Section 14.3,
+         MUST be taken.
+
+   L_HOLD_TIME
+
+      o  If L_HOLD_TIME changes, then the expiry times of all relevant
+         Link Tuples MUST be changed.
+
+   N_HOLD_TIME
+
+      o  If N_HOLD_TIME changes, then the expiry times of all relevant
+         Lost Neighbor Tuples MUST be changed.
+
+   HP_MAXJITTER
+
+      o  If HP_MAXJITTER changes, then the periodic HELLO message
+         schedule on this MANET interface MAY be changed.
+
+   HT_MAXJITTER
+
+      o  If HT_MAXJITTER changes, then externally triggered HELLO
+         messages on this MANET interface MAY be rescheduled.
+
+5.6.  Constants
+
+   The constant C (time granularity) is used as specified in [RFC5497].
+
+6.  Local Information Base
+
+   A router maintains a Local Information Base that records information
+   about its interfaces (MANET and non-MANET).  Each interface of a
+   router MUST be identified by at least one network address.  Such
+
+
+
+Clausen, et al.              Standards Track                   [Page 24]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   network addresses MAY be specific to that interface, or MAY in some
+   circumstances be used by more than one interface as specified below.
+
+   The Local Information Base is not modified by signaling.  If a
+   router's interface configuration changes, then the Local Information
+   Base MUST reflect these changes.  This MAY also result in signaling
+   to advertise these changes.
+
+   It is not necessary to include all addresses of an interface in the
+   Local Information Base, and hence in HELLO messages.  However, any
+   address that may be the source address of an IP datagram sent from
+   that interface MUST be included (and at least one address MUST be
+   included).  A protocol using this specification MAY add additional
+   requirements to these, e.g., that any address that may be the
+   destination address of an IP datagram is also included.
+
+   The addresses assigned to an interface are "owned" by the router, and
+   MUST NOT be used by any other router as an interface address.  If an
+   address has a prefix length and represents a range of addresses, this
+   applies to all addresses in that range (i.e., such ranges MUST NOT
+   overlap).
+
+   The addresses assigned to different interfaces on the same router
+   MUST be distinct (hence, network address ranges MUST NOT overlap)
+   except that:
+
+   o  The same address MAY be assigned to any number of non-MANET
+      interfaces as well as to one (or more if the following condition
+      also applies) MANET interface.
+
+   o  The same address MAY be assigned to two (or more if each pair
+      satisfies this condition) MANET interfaces if those two MANET
+      interfaces cannot communicate to, from, or one to and one from any
+      other MANET interface of another router.
+
+6.1.  Local Interface Set
+
+   A router's Local Interface Set records its local interfaces.  It
+   consists of Local Interface Tuples, one per interface:
+
+      (I_local_iface_addr_list, I_manet)
+
+   where:
+
+      I_local_iface_addr_list is an unordered list of the network
+      addresses of this interface.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 25]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+      I_manet is a boolean flag, describing if this interface is a MANET
+      interface.
+
+   Local Interface Tuples are removed from the Local Interface Set only
+   when the routers' interface configuration changes, subject to
+   Section 9, i.e., they are not subject to timer-based expiration.
+
+6.2.  Removed Interface Address Set
+
+   A router's Removed Interface Address Set records network addresses
+   that were recently used as local interface network addresses.  If a
+   router's interface network addresses are immutable, then the Removed
+   Interface Address Set is always empty and MAY be omitted.  It
+   consists of Removed Interface Address Tuples, one per network
+   address:
+
+      (IR_local_iface_addr, IR_time)
+
+   where:
+
+      IR_local_iface_addr is a recently used network address of an
+      interface of this router.
+
+      IR_time specifies when this Tuple expires and MUST be removed.
+
+7.  Interface Information Bases
+
+   A router maintains an Interface Information Base for each of its
+   MANET interfaces.  This records information about links to that MANET
+   interface and symmetric 2-hop neighbors that can be reached in two
+   hops using those links as the first hop.  Each Interface Information
+   Base includes a Link Set and a 2-Hop Set.
+
+   A network address of a symmetric 2-hop neighbor can also be present
+   as the network address of a 1-hop neighbor.  This allows the router
+   using this network address to be immediately considered as a
+   symmetric 2-hop neighbor if it fails to be a symmetric 1-hop
+   neighbor.
+
+   An element that specifies a time is considered expired if the current
+   time is greater than or equal to that time.  One such element,
+   present in most Tuples, indicates, when expired, that the Tuple
+   itself is considered expired and MUST be removed.  Tuples that do not
+   have such a time element are removed at other times as specified; for
+   example, a Neighbor Tuple is removed when all corresponding Link
+   Tuples have been removed.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 26]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+7.1.  Link Set
+
+   An interface's Link Set records links from other routers that are, or
+   recently were, 1-hop neighbors.  It consists of Link Tuples, each
+   representing a single link:
+
+      (L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time,
+       L_quality, L_pending, L_lost, L_time)
+
+   where:
+
+      L_neighbor_iface_addr_list is an unordered list of the network
+      addresses of the MANET interface of the 1-hop neighbor;
+
+      L_HEARD_time is the time up to which the MANET interface of the
+      1-hop neighbor would be considered heard if not considering link
+      quality;
+
+      L_SYM_time is the time up to which the link to the 1-hop neighbor
+      would be considered symmetric if not considering link quality;
+
+      L_quality is a dimensionless number between 0 (inclusive) and 1
+      (inclusive) describing the quality of a link; a greater value of
+      L_quality indicating a higher quality link;
+
+      L_pending is a boolean flag, describing if a link is considered
+      pending (i.e., a candidate, but not yet established, link);
+
+      L_lost is a boolean flag, describing if a link is considered lost
+      due to low link quality;
+
+      L_time specifies when this Tuple expires and MUST be removed.
+
+   The status of the link, as obtained through HELLO message exchange
+   and using link quality, is denoted L_status.  L_status can take the
+   Values PENDING, HEARD, SYMMETRIC, and LOST.  The values LOST,
+   SYMMETRIC, and HEARD are defined in Section 18.5.  The Value PENDING
+   is never used in a HELLO message, it is only used locally by a
+   router, and any Value distinct from LOST, SYMMETRIC, and HEARD may be
+   used.
+
+   L_status is defined by:
+
+   1.  If L_pending = true, then L_status := PENDING;
+
+   2.  otherwise, if L_lost = true, then L_status := LOST;
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 27]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   3.  otherwise, if L_SYM_time is not expired, then L_status :=
+       SYMMETRIC;
+
+   4.  otherwise, if L_HEARD_time is not expired, then L_status :=
+       HEARD;
+
+   5.  otherwise, L_status := LOST.
+
+7.2.  2-Hop Set
+
+   An interface's 2-Hop Set records network addresses of symmetric 2-hop
+   neighbors, and the symmetric links to symmetric 1-hop neighbors
+   through which these symmetric 2-hop neighbors can be reached.  It
+   consists of 2-Hop Tuples, each representing a single network address
+   of a symmetric 2-hop neighbor, and a single MANET interface of a
+   symmetric 1-hop neighbor.
+
+      (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)
+
+   where:
+
+      N2_neighbor_iface_addr_list is an unordered list of the network
+      addresses of the MANET interface of the symmetric 1-hop neighbor
+      from which this information was received;
+
+      N2_2hop_addr is a network address of a symmetric 2-hop neighbor
+      that has a symmetric link (using any MANET interface) to the
+      indicated symmetric 1-hop neighbor;
+
+      N2_time specifies when this Tuple expires and MUST be removed.
+
+8.  Neighbor Information Base
+
+   Each router maintains a Neighbor Information Base that records
+   information about network addresses of current and recently symmetric
+   1-hop neighbors.
+
+8.1.  Neighbor Set
+
+   A router's Neighbor Set records all network addresses of each 1-hop
+   neighbor.  It consists of Neighbor Tuples, each representing a single
+   1-hop neighbor:
+
+      (N_neighbor_addr_list, N_symmetric)
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 28]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   where:
+
+      N_neighbor_addr_list is an unordered list of the network addresses
+      of a 1-hop neighbor;
+
+      N_symmetric is a boolean flag, describing if this is a symmetric
+      1-hop neighbor.
+
+   Neighbor Tuples are removed from the Neighbor Set only when
+   corresponding Link Tuples expire from the routers' Link Set, i.e.,
+   Neighbor Tuples are not directly subject to timer-based expiration.
+
+8.2.  Lost Neighbor Set
+
+   A router's Lost Neighbor Set records network addresses of routers
+   that recently were symmetric 1-hop neighbors but that are now
+   advertised as lost.  It consists of Lost Neighbor Tuples, each
+   representing a single such network address:
+
+      (NL_neighbor_addr, NL_time)
+
+   where:
+
+      NL_neighbor_addr is a network address of a router that recently
+      was a symmetric 1-hop neighbor of this router;
+
+      NL_time specifies when this Tuple expires and MUST be removed.
+
+9.  Local Information Base Changes
+
+   The Local Information Base MUST be updated in response to changes in
+   the router's local interface configuration.  These MAY also change
+   the Interface Information Base and the Neighbor Information Base.  If
+   any changes to the latter Information Bases satisfy any of the
+   conditions described in Section 13, then those changes MUST be
+   applied immediately, unless noted otherwise below.
+
+   A router MAY transmit HELLO messages in response to these changes.
+
+9.1.  Adding an Interface
+
+   If an interface is added to the router, then this is indicated by the
+   addition of a Local Interface Tuple to the Local Interface Set.  If
+   the new interface is a MANET interface, then an initially empty
+   Interface Information Base MUST be created for this new MANET
+   interface.  The actions in Section 9.3 MUST be taken for each network
+   address of this added interface.  A HELLO message MAY be sent on all
+   MANET interfaces, it SHOULD be sent on the new interface if it is a
+
+
+
+Clausen, et al.              Standards Track                   [Page 29]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   MANET interface.  If using scheduled messages, then a message
+   schedule MUST be established on the new MANET interface.
+
+9.2.  Removing an Interface
+
+   If an interface is removed from the router, then this MUST result in
+   changes to the Local Information Base and to the Neighbor Information
+   Base as follows:
+
+   1.  Identify the Local Interface Tuple that corresponds to the
+       interface to be removed.
+
+   2.  For each network address (henceforth removed address) in the
+       I_local_iface_addr_list of that Local Interface Tuple, if that
+       network address is not in the I_local_iface_addr_list of any
+       other Local Interface Tuple, then create a Removed Interface
+       Address Tuple with:
+
+       o  IR_local_iface_addr := removed address;
+
+       o  IR_time := current time + I_HOLD_TIME.
+
+   3.  Remove that Local Interface Tuple from the Local Interface Set.
+
+   4.  If the interface to be removed is a MANET interface (i.e., with
+       I_manet = true), then:
+
+       1.  Remove the Interface Information Base for that MANET
+           interface;
+
+       2.  All Neighbor Tuples for which none of the network addresses
+           in its N_neighbor_addr_list are contained in any
+           L_neighbor_iface_addr_list in any remaining Link Tuple are
+           removed.
+
+   If the removed interface is the last MANET interface of the router,
+   then there will be no remaining Interface Information Bases, and the
+   router will no longer participate in this protocol.
+
+   After removing the interface and making these changes, a HELLO
+   message MAY be sent on all remaining MANET interfaces.
+
+9.3.  Adding a Network Address to an Interface
+
+   If a network address is added to an interface, then this is indicated
+   by the addition of a network address to the appropriate
+   I_local_iface_addr_list.  The following changes MUST be made to the
+   Information Bases:
+
+
+
+Clausen, et al.              Standards Track                   [Page 30]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   1.  Remove any Removed Interface Address Tuple whose
+       IR_local_iface_addr is the added network address.
+
+   2.  Remove any Neighbor Tuples whose N_neighbor_addr_list contains a
+       network address that overlaps the added network address.
+
+   3.  Remove any Link Tuples, in any Link Set, for which either:
+
+       o  L_neighbor_iface_addr_list contains any network address in the
+          N_neighbor_addr_list of any removed Neighbor Tuple; OR
+
+       o  L_neighbor_iface_addr_list contains a network address that
+          overlaps the added network address.
+
+       Apply Section 13.2 but not Section 13.3.
+
+   4.  Remove any Lost Neighbor Tuples whose NL_neighbor_addr overlaps
+       the added network address.
+
+   5.  Remove any 2-Hop Tuples whose N2_2hop_addr overlaps the added
+       network address.
+
+   After adding the network address and making these changes, a HELLO
+   message MAY be sent on all MANET interfaces.
+
+   These changes, other than to the appropriate I_local_iface_addr_list,
+   are made in order to maintain consistency of the Information Bases.
+   Specifically, these changes remove any record of any use of this
+   network address by routers in the 1-hop neighborhood or in the
+   symmetric 2-hop neighborhood of this router.
+
+9.4.  Removing a Network Address from an Interface
+
+   If a network address (henceforth removed address) is removed from an
+   interface, then:
+
+   1.  Identify the Local Interface Tuple that corresponds to the
+       removed address.
+
+   2.  If this is the only network address of that interface (the only
+       network address in the corresponding I_local_iface_addr_list),
+       then remove that interface as specified in Section 9.2.
+
+   3.  Otherwise:
+
+       1.  Remove the removed address from this I_local_iface_addr_list.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 31]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+       2.  If the removed address is not in the I_local_iface_addr_list
+           of any other Local Interface Tuple, then create a Removed
+           Interface Address Tuple with:
+
+           o  IR_local_iface_addr := removed address;
+
+           o  IR_time := current time + I_HOLD_TIME.
+
+   After removing the network address and making these changes, a HELLO
+   message MAY be sent on all MANET interfaces.
+
+10.  Packets and Messages
+
+   The packet and message format used by this protocol is defined in
+   [RFC5444], which is used with the following considerations:
+
+   o  This protocol specifies one Message Type, the HELLO message.
+
+   o  A HELLO message MAY use any combination of Message Header options
+      specified in [RFC5444].
+
+   o  HELLO messages MUST NOT be forwarded, i.e., a <msg-hop-limit>, if
+      present, MUST have the value 1.
+
+   o  HELLO messages MAY be included in multi-message packets as
+      specified in [RFC5444].
+
+   o  Received HELLO messages MUST be parsed in accordance with
+      [RFC5444].  A HELLO message that is not in conformance with
+      [RFC5444] MUST be discarded without being processed.  A HELLO
+      message can also be discarded without being processed for other
+      reasons, see Section 12.1.
+
+   o  This protocol specifies three Address Block TLVs.  It also uses
+      two Message TLVs defined in [RFC5497].  These five TLV Types are
+      all defined only with Type Extension = 0.  TLVs of other types,
+      and of these types but without Type Extension = 0, are ignored by
+      this protocol.  All references in this specification to, for
+      example, an Address Block TLV with Type = LINK_STATUS, are to be
+      considered as referring to an Address Block TLV with Type =
+      LINK_STATUS and Type Extension = 0.
+
+10.1.  HELLO Messages
+
+   A HELLO message MUST contain:
+
+   o  Exactly one VALIDITY_TIME Message TLV as specified in [RFC5497],
+      representing H_HOLD_TIME for the transmitting MANET interface.
+
+
+
+Clausen, et al.              Standards Track                   [Page 32]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+      The options included in [RFC5497] for representing zero and
+      infinite times MUST NOT be used.
+
+   A HELLO message transmitted due to a periodic timer SHOULD contain,
+   and otherwise (i.e., transmitted for any other reason, in particular
+   in response to any Information Base changes) MAY contain:
+
+   o  Exactly one INTERVAL_TIME Message TLV as specified in [RFC5497],
+      representing HELLO_INTERVAL for the transmitting MANET interface.
+      The options included in [RFC5497] for representing zero and
+      infinite times MUST NOT be used.
+
+   A HELLO message MAY contain:
+
+   o  Other Message TLVs.
+
+   o  One or more Address Blocks, each with an associated Address Block
+      TLV Block, which MAY contain other Address Block TLVs.
+
+10.1.1.  Address Blocks
+
+   All network addresses in a router's Local Interface Set (i.e., in any
+   I_local_iface_addr_list) MUST be represented as address objects (see
+   [RFC5444]), and included in the Address Blocks in all generated HELLO
+   messages, with the following permitted exception:
+
+   o  If the MANET interface on which the HELLO message is to be sent
+      has a single address with maximum prefix length (i.e., /32 for
+      IPv4, /128 for IPv6), then that address MAY be omitted from being
+      included in any Address Block, provided that this address is
+      included as the sending address of the IP datagram in which the
+      HELLO message is included.
+
+   All network addresses of the router's interfaces included in any
+   Address Block(s) MUST be associated with an Address Block TLV with
+   Type = LOCAL_IF, as defined in Table 1.
+
+   +----------+---------+----------------------------------------------+
+   |   Name   |  Value  | Description                                  |
+   |          |  Length |                                              |
+   +----------+---------+----------------------------------------------+
+   | LOCAL_IF | 1 octet | Specifies that the network address is        |
+   |          |         | associated with the MANET interface on which |
+   |          |         | the message was sent (THIS_IF) or another    |
+   |          |         | interface of the sending router (OTHER_IF).  |
+   +----------+---------+----------------------------------------------+
+
+                     Table 1: LOCAL_IF TLV Definition
+
+
+
+Clausen, et al.              Standards Track                   [Page 33]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   Address Blocks MAY contain current or recently lost 1-hop neighbors'
+   network addresses, represented as address objects (see [RFC5444]),
+   each of which is associated with one or both Address Block TLVs as
+   described in Table 2.
+
+   +--------------+---------+------------------------------------------+
+   |     Name     |  Value  | Description                              |
+   |              |  Length |                                          |
+   +--------------+---------+------------------------------------------+
+   |  LINK_STATUS | 1 octet | Specifies the status of the link from    |
+   |              |         | the indicated network address and to the |
+   |              |         | MANET interface over which the HELLO     |
+   |              |         | message is transmitted (LOST, SYMMETRIC, |
+   |              |         | or HEARD).                               |
+   | OTHER_NEIGHB | 1 octet | Specifies that the network address is    |
+   |              |         | (SYMMETRIC) or was (LOST) of a MANET     |
+   |              |         | interface of a symmetric 1-hop neighbor  |
+   |              |         | of the router transmitting the HELLO     |
+   |              |         | message.                                 |
+   +--------------+---------+------------------------------------------+
+
+           Table 2: LINK_STATUS and OTHER_NEIGHB TLV Definition
+
+   An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or
+   Value = LOST also performs the function of an Address Block TLV with
+   Type = OTHER_NEIGHB and the same Value.  Including the latter
+   associated with the same address object is discouraged for efficiency
+   reasons.  If an Address Block TLV with Type = LINK_STATUS and Value =
+   SYMMETRIC is combined with an Address Block TLV with Type =
+   OTHER_NEIGHB and Value = LOST associated with the same address
+   object, then the latter MUST be ignored and SHOULD NOT be included.
+   See Appendix A.
+
+   Other network addresses MAY be represented as address objects (see
+   [RFC5444]) and included in Address Blocks, but MUST NOT be associated
+   with any of the Address Block TLVs specified in this specification.
+
+11.  HELLO Message Generation
+
+   Each MANET interface MUST generate HELLO messages according to the
+   specification in this section.  HELLO messages are generated for each
+   MANET interface independently.  HELLO message generation and
+   scheduling MUST be according to the interface parameters for that
+   MANET interface, and MAY be independent for each MANET interface or,
+   interface parameters permitting, MANET interfaces MAY use the same
+   schedule.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 34]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   If transmitting periodic HELLO messages, then, following a HELLO
+   message transmission on a MANET interface, another HELLO message MUST
+   be transmitted on the same MANET interface after an interval not
+   greater than HELLO_INTERVAL.  Two successive HELLO message
+   transmissions on the same MANET interface MUST be separated by at
+   least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1.
+
+11.1.  HELLO Message Specification
+
+   HELLO messages are generated independently on each MANET interface.
+
+   All network addresses in any I_local_iface_addr_list MUST be
+   included, represented as address objects (see [RFC5444]), except
+   that:
+
+   o  If the interface on which the HELLO message is to be sent has a
+      single address with maximum prefix length (i.e., /32 for IPv4,
+      /128 for IPv6), then that address MAY be omitted, provided that
+      this address is included as the sending address of the IP datagram
+      in which the HELLO message is included.
+
+   All such included address objects MUST be associated with an Address
+   Block TLV with Type := LOCAL_IF and Value according to the following:
+
+   o  If the address object represents a network address of the sending
+      MANET interface, then Value := THIS_IF.
+
+   o  Otherwise, Value := OTHER_IF.
+
+   If such a network address is included in more than one
+   I_local_iface_addr_list, then, for efficiency reasons, it is
+   encouraged that the corresponding address object is associated with
+   only one Value using an Address Block TLV with Type := LOCAL_IF; this
+   MUST be Value := THIS_IF if the address object represents a network
+   address of the sending MANET interface.
+
+   The following network addresses of current or former 1-hop neighbors
+   MAY be represented as address objects (see [RFC5444]) and included in
+   any HELLO message, respecting the parameter REFRESH_INTERVAL for each
+   association for that MANET interface, and according to the following:
+
+   o  Network addresses of MANET interfaces of 1-hop neighbors from the
+      Link Set of the Interface Information Base for this MANET
+      interface (i.e., from an L_neighbor_iface_addr_list), other than
+      those from Link Tuples with L_status = PENDING.
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 35]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   o  Other network addresses of symmetric 1-hop neighbors from the
+      Neighbor Set of this router's Neighbor Information Base (i.e.,
+      from an N_neighbor_addr_list).
+
+   o  Network addresses of MANET interfaces of previously symmetric or
+      heard 1-hop neighbors connected on this MANET interface from the
+      Link Set of the Interface Information Base for this MANET
+      interface (i.e., from an L_neighbor_iface_addr_list with L_status
+      = LOST).
+
+   o  Other network addresses of previously symmetric 1-hop neighbors
+      from the Lost Neighbor Set of this router's Neighbor Information
+      Base (i.e., from an NL_neighbor_addr).
+
+   Each such address object (see [RFC5444]) MUST be associated with one
+   or more appropriate Address Block TLVs.  Specifically:
+
+   1.  For each address object (henceforth linked address) that
+       represents a network address contained in an
+       L_neighbor_iface_addr_list of a Link Tuple in the Link Set for
+       this MANET interface, for which L_status != PENDING, include the
+       linked address with an associated Address Block TLV with:
+
+       o  Type := LINK_STATUS; AND
+
+       o  Value := L_status.
+
+   2.  For each address object (henceforth neighbor address) that
+       represents a network address contained in an N_neighbor_addr_list
+       in a Neighbor Tuple with N_symmetric = true and that has not
+       already been included with an associated Address Block TLV with
+       Type = LINK_STATUS and Value = SYMMETRIC, include the neighbor
+       network address with an associated Address Block TLV with:
+
+       o  Type := OTHER_NEIGHB; AND
+
+       o  Value := SYMMETRIC.
+
+   3.  For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth
+       lost address) has not already been represented as an address
+       object and included, include lost address with an associated
+       Address Block TLV with:
+
+       o  Type := OTHER_NEIGHB; AND
+
+       o  Value := LOST.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 36]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   If any such network addresses have been added to these Information
+   Bases since the last HELLO message was sent on this MANET interface,
+   or if their status (as indicated by these TLVs and the Values they
+   associate with that network address) have changed since that network
+   address was last reported on this MANET interface, then that network
+   address, and the indicated TLVs, SHOULD be included in the HELLO
+   message.
+
+   If the address object (see [RFC5444]) representing a network address
+   of a 1-hop neighbor is specified with more than one associated
+   Address Block TLV, then these Address Block TLVs MAY be independently
+   included or excluded from each HELLO message.  Each such Address
+   Block TLV MUST be included associated with the address object
+   representation of that network address in a HELLO message sent on
+   that MANET interface in every interval of length equal to that MANET
+   interface's parameter REFRESH_INTERVAL.  Address Block TLVs
+   associated with the same address object included in the same HELLO
+   message MAY be applied to the same or different copies of that
+   address object.
+
+   An implementation of this protocol MAY limit the information included
+   in each HELLO message, for example, to accommodate smaller MTU sizes.
+   HELLO messages remain constrained by the above requirements, in
+   particular, that all local interface information MUST be included in
+   all HELLO messages, and that all neighbor information MUST be sent
+   within each interval of length REFRESH_INTERVAL.  This neighbor
+   information MAY, however, be sent in the same or in different HELLO
+   messages.
+
+11.2.  HELLO Message Transmission
+
+   HELLO messages are transmitted in the format specified by [RFC5444].
+
+11.2.1.  HELLO Message Jitter
+
+   HELLO messages MAY be sent using periodic message generation or
+   externally triggered message generation.  If using data link and
+   physical layers that are subject to packet loss due to collisions,
+   HELLO messages SHOULD be jittered as described in [RFC5148].
+
+   Internally triggered message generation (such as due to a change in
+   local interfaces) MAY be treated as if externally generated message
+   generation or MAY be not jittered.
+
+   HELLO messages MUST NOT be forwarded, and thus message forwarding
+   jitter does not apply to HELLO messages.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 37]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   Each form of jitter described in [RFC5148] requires a parameter
+   MAXJITTER.  These interface parameters may be dynamic and are
+   specified by:
+
+   o  For periodic message generation: HP_MAXJITTER.
+
+   o  For externally triggered message generation: HT_MAXJITTER.
+
+   When HELLO message generation is delayed in order that a HELLO
+   message is not sent within HELLO_MIN_INTERVAL of the previous HELLO
+   message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD
+   be reduced by jitter, with maximum reduction HP_MAXJITTER, as
+   described in [RFC5148].  In this case, HP_MAXJITTER MUST NOT be
+   greater than HELLO_MIN_INTERVAL.
+
+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.)
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 38]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   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.
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 39]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   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
+
+
+
+Clausen, et al.              Standards Track                   [Page 40]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+      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.
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 41]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+           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.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 42]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   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:
+
+
+
+Clausen, et al.              Standards Track                   [Page 43]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+                   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
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 44]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+               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.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 45]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   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.
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 46]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   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;
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 47]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+               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.
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 48]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+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.
+
+
+
+Clausen, et al.              Standards Track                   [Page 49]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   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.)
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 50]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+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
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 51]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+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
+
+
+
+Clausen, et al.              Standards Track                   [Page 52]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+      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.
+
+
+
+Clausen, et al.              Standards Track                   [Page 53]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   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.
+
+
+
+Clausen, et al.              Standards Track                   [Page 54]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   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.
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 55]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   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.
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 56]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+      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].
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 57]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+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
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 58]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+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
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 59]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   +--------------+------+-----------+--------------------+------------+
+   |     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
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 60]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 61]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 62]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+Appendix A.  Address Block TLV Combinations
+
+   The algorithm for generating HELLO messages in Section 11 specifies
+   which 1-hop neighbor network addresses may be included in the Address
+   Blocks, and with which associated Address Block TLVs.  These Address
+   Block TLVs may have Type = LINK_STATUS or Type = OTHER_NEIGHB, or
+   both.  Address Block TLVs with Type = LINK_STATUS may have three
+   possible Values (Value = HEARD, Value = SYMMETRIC, or Value = LOST),
+   and Address Block TLVs of TYPE = OTHER_NEIGHB may have two possible
+   Values (Value = SYMMETRIC or Value = LOST).  When both Address Block
+   TLVs are associated with the same network address only certain
+   combinations of these Address Block TLV Values are necessary, and are
+   the only combinations generated by the algorithm in Section 11.
+   These combinations are indicated in Table 9.
+
+   Cells labeled with "Yes" indicate the possible combinations that are
+   generated by the algorithm in Section 11.  Cells labeled with "No"
+   indicate combinations not generated by the algorithm in Section 11
+   but that are correctly parsed and interpreted by the algorithm in
+   Section 12.  The cell labeled with "No*" is actually inconsistent, it
+   is handled by ignoring the Address Block TLV with Type =
+   OTHER_NEIGHB, but SHOULD NOT be used.
+
+   +----------------+----------------+----------------+----------------+
+   |                |     Type =     |     Type =     |     Type =     |
+   |                |  OTHER_NEIGHB  |  OTHER_NEIGHB, |  OTHER_NEIGHB, |
+   |                |    (absent)    |     Value =    |  Value = LOST  |
+   |                |                |    SYMMETRIC   |                |
+   +----------------+----------------+----------------+----------------+
+   | Type =         |       No       |       Yes      |       Yes      |
+   | LINK_STATUS    |                |                |                |
+   | (absent)       |                |                |                |
+   | Type =         |       Yes      |       Yes      |       Yes      |
+   | LINK_STATUS,   |                |                |                |
+   | Value = HEARD  |                |                |                |
+   | Type =         |       Yes      |       No       |       No*      |
+   | LINK_STATUS,   |                |                |                |
+   | Value =        |                |                |                |
+   | SYMMETRIC      |                |                |                |
+   | Type =         |       Yes      |       Yes      |       No       |
+   | LINK_STATUS,   |                |                |                |
+   | Value = LOST   |                |                |                |
+   +----------------+----------------+----------------+----------------+
+
+          Table 9: LINK_STATUS and OTHER_NEIGHB TLV Combinations
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 63]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+Appendix B.  Constraints
+
+   Any process that updates the Local Information Base or the Neighbor
+   Information Base MUST ensure that all constraints specified in this
+   appendix are maintained.
+
+   In each Local Interface Tuple:
+
+   o  I_local_iface_addr_list MUST NOT be empty.
+
+   o  I_local_iface_addr_list MUST NOT contain any duplicated network
+      addresses.
+
+   o  If I_manet = true, then I_local_iface_addr_list MUST NOT contain
+      any network address that overlaps any network address in the
+      I_local_iface_addr_list of any other Local Interface Tuple with
+      I_manet = true, unless it is known that the corresponding MANET
+      interfaces will always communicate with separate sets of MANET
+      interfaces on other routers.
+
+   In each Removed Interface Address Tuple:
+
+   o  IR_local_iface_addr MUST NOT contain any network address that is
+      in the I_local_iface_addr_list of any Local Interface Tuple.
+
+   o  IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any
+      other Removed Interface Address Tuple.
+
+   In each Link Tuple:
+
+   o  L_neighbor_iface_addr_list MUST NOT be empty.
+
+   o  L_neighbor_iface_addr_list MUST NOT contain any network address
+      that overlaps any network address in the I_local_iface_addr_list
+      of any Local Interface Tuple or the IR_local_iface_addr of any
+      Removed Interface Address Tuple.
+
+   o  L_neighbor_iface_addr_list MUST NOT contain any duplicated network
+      addresses.
+
+   o  L_neighbor_iface_addr_list MUST NOT contain any network address
+      which is in the L_neighbor_iface_addr_list of any other Link Tuple
+      in the same Link Set.
+
+   o  If L_HEARD_time has not expired, then there MUST be a Neighbor
+      Tuple whose N_neighbor_addr_list contains
+      L_neighbor_iface_addr_list.
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 64]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   o  L_HEARD_time MUST NOT be greater than L_time.
+
+   o  L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are
+      expired).
+
+   o  L_quality MUST NOT be less than 0 or greater than 1.
+
+   o  If L_quality >= HYST_ACCEPT, then L_pending MUST be false.
+
+   o  If L_quality < HYST_REJECT, then L_status MUST be PENDING or LOST.
+
+   o  L_pending MUST NOT be set to true if it is currently false.
+
+   In each Neighbor Tuple:
+
+   o  N_neighbor_addr_list MUST NOT contain any network address that
+      overlaps any network address in the I_local_iface_addr_list of any
+      Local Interface Tuple or the IR_local_iface_addr of any Removed
+      Interface Address Tuple.
+
+   o  N_neighbor_addr_list MUST NOT contain any duplicated network
+      addresses.
+
+   o  N_neighbor_addr_list MUST NOT contain any network address that is
+      in the N_neighbor_addr_list of any other Neighbor Tuple.
+
+   o  If N_symmetric is = true, then there MUST be one or more Link
+      Tuples with:
+
+      o  L_neighbor_iface_addr_list contained in N_neighbor_addr_list;
+         AND
+
+      o  L_status = SYMMETRIC.
+
+   o  If N_symmetric is = false, then there MUST be one or more Link
+      Tuples with:
+
+      o  L_neighbor_iface_addr_list contained in N_neighbor_addr_list.
+
+      All such Link Tuples MUST NOT have L_status = SYMMETRIC.  At least
+      one such Link Tuple MUST have L_HEARD_time not expired.
+
+   In each Lost Neighbor Tuple:
+
+   o  NL_neighbor_addr MUST NOT overlap any network address in the
+      I_local_iface_addr_list of any Local Interface Tuple or the
+      IR_local_iface_addr of any Removed Interface Address Tuple.
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 65]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   o  NL_neighbor_addr MUST NOT equal the NL_neighbor_addr of any other
+      Lost Neighbor Tuple.
+
+   o  NL_neighbor_addr MUST NOT be in the N_neighbor_addr_list of any
+      Neighbor Tuple with N_symmetric = true.
+
+   In each 2-Hop Tuple:
+
+   o  There MUST be a Link Tuple associated with the same MANET
+      interface with:
+
+      o  L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND
+
+      o  L_status = SYMMETRIC.
+
+   o  N2_2hop_addr MUST NOT overlap any network address in the
+      I_local_iface_addr_list of any Local Interface Tuple or the
+      IR_local_iface_addr of any Removed Interface Address Tuple.
+
+   o  N2_2hop_addr MUST NOT be the N2_2hop_addr of any other 2-Hop Tuple
+      in the same 2-Hop Set and with the same
+      N2_neighbor_iface_addr_list.
+
+   o  N2_2hop_addr MUST NOT be in the N2_neighbor_iface_addr_list of the
+      same 2-Hop Tuple.
+
+Appendix C.  HELLO Message Example
+
+   HELLO messages are instances of [RFC5444] messages, and this protocol
+   supports any combination of message header options and address
+   encodings, enabled by [RFC5444] that convey the required information.
+   As a consequence, there is no single way to represent how all HELLO
+   messages look.  This appendix illustrates two HELLO message with
+   similar content, the exact values included are explained in the
+   following text.
+
+   The HELLO message's four bit Message Flags (MF) field has value 7
+   indicating that the message header contains hop limit, hop count, and
+   message sequence number fields.  Its four bit Message Address Length
+   (MAL) field has value 3, indicating addresses in the message have a
+   length of four octets, here being IPv4 addresses.  The message is as
+   transmitted, with a hop limit of 1 and a hop count of 0.  The overall
+   message length is 45 octets.
+
+   The message contains a Message TLV Block with content length 8 octets
+   containing two Message TLVs, of types VALIDITY_TIME and
+   INTERVAL_TIME.  Each uses a Message TLV with Flags octet (MTLVF)
+   value 16, indicating that each has a Value, and each has a Value
+
+
+
+Clausen, et al.              Standards Track                   [Page 66]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   Length of 1 octet.  The Values included are time codes (as defined in
+   [RFC5497]) representing the parameters H_HOLD_TIME and
+   HELLO_INTERVAL, respectively.
+
+   The message has a single Address Block containing 5 addresses.  The
+   Address Block Flags octet (ABF) value 128 indicates an address Head
+   but no address Tail, and no address prefixes.  The Head Length of 3
+   octets indicates address Mid sections of one octet each (Mid 0 to Mid
+   4).
+
+   The following Address Block TLV Block (content length 14 octets)
+   includes two Address Block TLVs.  The first is a LOCAL_IF Address
+   Block TLV with Flags octet (ATLVF) value 80, which indicates that a
+   single address, with index 0 (i.e., the address Head:Mid 0) is the
+   single local interface address of this router (the one octet Value
+   THIS_IF indicates that this address is of this interface).  The
+   second is a LINK_STATUS Address Block TLV with Flags octet (ATLVF)
+   value 52, which specifies the link status values of all reported
+   neighbors in a single multivalue Address Block TLV that covers the
+   addresses with indexes 1 to 4, inclusive.  The Address Block TLV
+   Value Length of 4 octets indicates one octet per Value per address.
+   The last four addresses thus are of neighbors, each an with
+   associated link status: the first and second HEARD, the third
+   SYMMETRIC, and the fourth LOST.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 67]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     HELLO     | MF=7  | MAL=3 |      Message Length = 45      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Hop Limit = 1 | Hop Count = 0 |    Message Sequence Number    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Message TLV Block Length = 8  | VALIDITY_TIME |  MTLVF = 16   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Value Len = 1 | Value (Time)  | INTERVAL_TIME |  MTLVF = 16   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Value Len = 1 | Value (Time)  | Num Addrs = 5 |   ABF = 128   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Head Len = 3  |                     Head                      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Mid 0     |     Mid 1     |     Mid 2     |     Mid 3     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Mid 4     | Address TLV Block Length = 14 |   LOCAL_IF    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  ATLVF = 80   |   Index = 0   | Value Len = 1 |    THIS_IF    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  LINK_STATUS  |   ATLV = 52   | Strt Indx = 1 | Stop Indx = 4 |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Value Len = 4 |     HEARD     |     HEARD     |   SYMMETRIC   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     LOST      |
+     +-+-+-+-+-+-+-+-+
+
+   Note that this example is for illustrative purposes.  The essential
+   information can be conveyed, more efficiently (assuming that the
+   local interface address will be supplied by IP, and that the
+   INTERVAL_TIME TLV is not needed) by the 29 octets:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 68]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     HELLO     |0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 1 1|                     Head                      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Mid 1     |     Mid 2     |     Mid 3     |     Mid 4     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|  LINK_STATUS  |0 0 0 1 0 1 0 0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |0 0 0 0 0 1 0 0|     HEARD     |     HEARD     |   SYMMETRIC   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     LOST      |
+     +-+-+-+-+-+-+-+-+
+
+   Note that the above example assumes that H_HOLD_TIME and C have their
+   default values of 6 seconds and 1/1024 second, and thus result in a
+   time code of 100 (hexadecimal 64).
+
+Appendix D.  Flow and Congestion Control
+
+   This protocol specifies one Message Type, the HELLO message.  The
+   maximum size of a HELLO message is proportional to the size of the
+   originating router's 1-hop neighborhood.  HELLO messages MUST NOT be
+   forwarded.
+
+   A router MUST report its 1-hop neighborhood in HELLO messages on each
+   of its MANET interfaces at least each REFRESH_INTERVAL.  This puts a
+   lower bound on the control traffic generated by each router in the
+   network employing this protocol.
+
+   A router MUST ensure that two successive HELLO messages sent on the
+   same MANET interface are separated by at least HELLO_MIN_INTERVAL.
+   (If using jitter, then this may be reduced to a mean minimum value of
+   HELLO_MIN_INTERVAL - HP_MAXJITTER/2.)  Thus, this puts an upper bound
+   on the control traffic generated by each router in the network
+   employing this protocol.
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 69]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+Appendix E.  Interval and Timer Illustrations
+
+   This informative appendix illustrates the relationship between
+   message timers and intervals.  (The adjustments to this timing when
+   using timing jitter, as defined in [RFC5148], are not shown.)
+
+E.1.  HELLO Message Generation Timing
+
+   Figure 1 illustrates a basic HELLO message schedule for a router, on
+   a MANET interface, employing strictly periodic transmission of HELLO
+   messages.  The router transmits a HELLO message each HELLO_INTERVAL.
+   Each HELLO message contains all 1-hop neighbor network addresses of
+   the router that are to be reported in any such HELLO message.  (The
+   parameter REFRESH_INTERVAL, not shown, is in this example equal to
+   the parameter HELLO_INTERVAL.)
+
+   The router includes a VALIDITY_TIME TLV in each HELLO message,
+   encoding the parameter H_HOLD_TIME, the duration for which
+   information received in the HELLO message should be considered valid
+   by receiving routers.  Receiving routers will, when recording the
+   information received in the HELLO message, each use this for setting
+   the L_HEARD_time, L_SYM_time and L_time elements of their
+   corresponding Link Tuple, and the N2_time in the corresponding 2-Hop
+   Tuple for each network address.  Only L_time is illustrated in
+   Figure 1.
+
+     H_HOLD_TIME:         |-----------------------------|   ...
+
+     HELLO_INTERVAL:      |---------|---------|---------|   ...
+
+     Time:             ---*---------*---------*---------*------>
+
+                          ^         ^         ^         ^
+                          |         |         |         |
+         HELLO (a, b, c, d)         |         |         |
+                                    |         |         |
+                   HELLO (a, b, c, d)         |         |   ...
+                                              |         |
+                             HELLO (a, b, c, d)         |
+                                                        |
+                                       HELLO (a, b, c, d)
+
+     L_time:              |-----------------------------|
+                                    |--------------------   ...
+                                              |----------   ...
+                                                        |   ...
+
+           Figure 1: HELLO Message Generation: Regular Schedule
+
+
+
+Clausen, et al.              Standards Track                   [Page 70]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   Figure 2 illustrates a message schedule similar to Figure 1, where
+   the router announces its own presence more frequently by sending
+   additional HELLO messages.  HELLO messages are still sent regularly,
+   at a reduced interval defined by a new value of HELLO_INTERVAL.
+   However, REFRESH_INTERVAL has not been reduced.  Each 1-hop neighbor
+   network address included in these HELLO messages need be advertised
+   only once within each REFRESH_INTERVAL.  Consequently, the additional
+   HELLO messages due to the reduced value of HELLO_INTERVAL may
+   therefore be empty.  (This is not the only allowed distribution of
+   1-hop neighbor network addresses, they could, for example, be sent
+   alternately a, b and c, d.)
+
+     H_HOLD_TIME:         |-----------------------------|   ...
+
+     REFRESH_INTERVAL:    |---------|---------|---------|   ...
+
+     HELLO_INTERVAL:      |----|----|----|----|----|----|   ...
+
+     Time:             ---*---------*---------*---------*------>
+
+                          ^    ^    ^    ^    ^    ^    ^
+                          |    |    |    |    |    |    |
+         HELLO (a, b, c, d)    |    |    |    |    |    |
+                               |    |    |    |    |    |
+                        HELLO ()    |    |    |    |    |
+                                    |    |    |    |    |
+                   HELLO (a, b, c, d)    |    |    |    |
+                                         |    |    |    |   ...
+                                  HELLO ()    |    |    |
+                                              |    |    |
+                             HELLO (a, b, c, d)    |    |
+                                                   |    |
+                                            HELLO ()    |
+                                                        |
+                                       HELLO (a, b, c, d)
+
+     L_time:              |-----------------------------|
+                               |-------------------------   ...
+                                    |--------------------   ...
+                                         |---------------   ...
+                                              |----------   ...
+                                                   |-----   ...
+                                                        |   ...
+
+    Figure 2: HELLO Message Generation: Regular Schedule with Different
+                    HELLO_INTERVAL and REFRESH_INTERVAL
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 71]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   HELLO messages may also be sent in response to events.  The minimal
+   interval between two successive HELLO message transmissions by a
+   router is HELLO_MIN_INTERVAL, setting an upper bound of the HELLO
+   message emission rate.  Hence, for each HELLO message transmission, a
+   router must wait at least HELLO_MIN_INTERVAL before the next HELLO
+   message transmission.  Similarly, the maximum interval between two
+   successive HELLO message transmissions is HELLO_INTERVAL, setting a
+   lower bound on the message transmission rate.  Hence, for each HELLO
+   message transmission, the router must ensure that the next HELLO
+   message transmission must not wait more than HELLO_INTERVAL.
+
+   Figure 3 illustrates a message schedule similar to Figure 1, but with
+   HELLO messages responding to events at maximum rate, i.e., with HELLO
+   messages being sent each HELLO_MIN_INTERVAL.  Note that when a HELLO
+   message is sent, it is assumed that the following messages may all be
+   scheduled at an interval of HELLO_INTERVAL, and hence each HELLO
+   message contains all 1-hop neighbor network addresses.  In each HELLO
+   message in this example, a new 1-hop neighbor network address is
+   added, reflecting the changes occurring since the last HELLO message
+   was sent.  HELLO messages are sent at the maximum allowed rate in
+   order to signal these changes as rapidly as possible.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 72]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+     H_HOLD_TIME:         |-----------------------------|   ...
+
+     HELLO_INTERVAL:      |---------|---------|---------|   ...
+
+     HELLO_MIN_INTERVAL:  |----|----|----|----|----|----|   ...
+
+     Time:             ---*---------*---------*---------*------>
+
+                          ^    ^    ^    ^    ^    ^    ^
+                          |    |    |    |    |    |    |
+                   HELLO ()    |    |    |    |    |    |
+                               |    |    |    |    |    |
+                       HELLO (a)    |    |    |    |    |
+                                    |    |    |    |    |
+                         HELLO (a, b)    |    |    |    |
+                                         |    |    |    |   ...
+                           HELLO (a, b, c)    |    |    |
+                                              |    |    |
+                             HELLO (a, b, c, d)    |    |
+                                                   |    |
+                               HELLO (a, b, c, d, e)    |
+                                                        |
+                                 HELLO (a, b, c, d, e, f)
+
+     L_time:              |-----------------------------|
+                               |-------------------------   ...
+                                    |--------------------   ...
+                                         |---------------   ...
+                                              |----------   ...
+                                                   |-----   ...
+                                                        |   ...
+
+   Figure 3: HELLO Message Generation: Regular Schedule with Responsive
+                                 Messages
+
+   Figure 4 shows the same example as Figure 3, but with an increased
+   REFRESH_INTERVAL, and showing partial HELLO messages that include
+   only the necessary network addresses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 73]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+     H_HOLD_TIME:         |-----------------------------|   ...
+
+     REFRESH_INTERVAL:    |-------------------|----------   ...
+                               |-------------------|-----   ...
+                                    |-------------------|   ...
+                                         |---------------   ...
+                                              |----------   ...
+                                                   |-----   ...
+                                                        |   ...
+
+     HELLO_INTERVAL:      |---------|---------|---------|   ...
+
+     HELLO_MIN_INTERVAL:  |----|----|----|----|----|----|   ...
+
+     Time:             ---*---------*---------*---------*------>
+
+                          ^    ^    ^    ^    ^    ^    ^
+                          |    |    |    |    |    |    |
+                   HELLO ()    |    |    |    |    |    |
+                               |    |    |    |    |    |
+                       HELLO (a)    |    |    |    |    |
+                                    |    |    |    |    |
+                            HELLO (b)    |    |    |    |
+                                         |    |    |    |   ...
+                                 HELLO (c)    |    |    |
+                                              |    |    |
+                                   HELLO (a, d)    |    |
+                                                   |    |
+                                        HELLO (b, e)    |
+                                                        |
+                                             HELLO (c, f)
+
+     L_time:              |-----------------------------|
+                               |-------------------------   ...
+                                    |--------------------   ...
+                                         |---------------   ...
+                                              |----------   ...
+                                                   |-----   ...
+                                                        |   ...
+
+   Figure 4: HELLO Message Generation: Regular Schedule with Responsive
+        Messages and Different HELLO_INTERVAL and REFRESH_INTERVAL
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 74]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   Figure 5 summarizes the overall relationship between the intervals
+   governing HELLO message transmissions by a router.
+
+     H_HOLD_TIME:         |------------------------------------|
+
+     REFRESH_INTERVAL:    |----------------|
+
+     HELLO_INTERVAL:      |----------|
+
+     HELLO_MIN_INTERVAL:  |---|
+
+     Time:             ----------------------------------------------->
+
+                          ^   ^      ^     ^                   ^
+                          |   |      |     |                   |
+                          |   |      |     |           Time up to which
+              HELLO message   |      |     |           received HELLO
+              transmission    |      |     |           message content
+                              |      |     |           is valid.
+                              |      |     |
+                              |      |     Time before which all
+                              |      |     neighbor information must
+                              |      |     be transmitted in HELLO
+                              |      |     messages (one or more)
+                              |      |
+                              |      Latest time for next HELLO message
+                              |      transmission
+                              |
+                              Earliest time for next HELLO message
+                              transmission
+
+               Figure 5: HELLO Message Generation Intervals
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 75]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+E.2.  HELLO Message Processing Timing
+
+   Figure 6 illustrates the Link Set timers when receiving a HELLO
+   message not including the network address of the receiving MANET
+   interface.
+
+     VALIDITY_TIME:    |--------------------------|
+
+     L_time:           |--------------------------|
+
+     L_HEARD_time:     |--------------------------|
+
+     L_SYM_time:     *-| (i.e.,  expired)
+
+     Time:          ---*-------------------------------->
+                       ^
+                       |
+                HELLO () received
+
+      Figure 6: HELLO Message Processing: Network Address Not Present
+
+   Figure 7 illustrates the Link Set timers when, following the received
+   HELLO message illustrated in Figure 6, a router receives a HELLO
+   message including the network address (a) of the receiving interface
+   with link status = HEARD (or SYM).
+
+     VALIDITY_TIME:    |--------------------------|
+                             |--------------------------|
+
+     L_time:           |--------------------------|
+                             |--------------------------|
+
+     L_HEARD_time:     |--------------------------|
+                             |--------------------------|
+
+     L_SYM_time:     *-| (i.e.,  expired)
+     L_SYM_time:             |--------------------------|
+
+     Time:            -*-----*--------------------------------->
+                       ^     ^
+                       |     |
+      HELLO () received      |
+                             |
+      HELLO (a:HEARD) received
+
+        Figure 7: HELLO Message Processing: Network Address Present
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 76]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   Figure 8 illustrates the Link Set timers when, following the received
+   HELLO messages illustrated in Figure 7, a router receives a HELLO
+   message including the network address (a) of the receiving interface
+   with link status = LOST.
+
+     VALIDITY_TIME:    |--------------------------|
+                             |--------------------------|
+                                   |--------------------------|
+
+     L_time:           |--------------------------|
+                             |--------------------------|
+                                   |--------------------------|
+
+     L_HEARD_time:     |--------------------------|
+                             |--------------------------|
+                                   |--------------------------|
+
+     L_SYM_time:     *-| (i.e.,  expired)
+                             |--------------------------|
+                                 *-| (i.e.,  expired)
+
+     Time:            -*-----*-----*--------------------------------->
+                       ^     ^     ^
+                       |     |     |
+       HELLO () received     |     |
+                             |     |
+      HELLO (a:HEARD) received     |
+                                   |
+             HELLO (a:LOST) received
+
+         Figure 8: HELLO Message Processing: Network Address Lost
+
+E.3.  Other HELLO Message Timing
+
+   There are three other timing parameters that are used by a router to
+   control HELLO message generation and processing.
+
+   Figure 9 illustrates the time, with duration L_HOLD_TIME, during
+   which the appropriate network addresses of a formerly, but no longer,
+   symmetric 1-hop neighbor, as connected by this MANET interface, are
+   advertised as LOST using a LINK_STATUS TLV in HELLO messages on this
+   MANET interface, thus allowing that 1-hop neighbor to update its Link
+   Set accordingly.
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 77]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+     L_HOLD_TIME:   |----------------------------|
+
+     Time:       ---*---------------------------------->
+                    ^                            ^
+                    |                            |
+         Formerly symmetric 1-hop neighbor       |
+         ceases to be symmetric on this          |
+         MANET interface                         |
+                                                 |
+                      Time up to which network addresses of
+                      this neighbor connected using this MANET
+                      interface are advertised in HELLO
+                      messages on this MANET interface
+                      using a LINK_STATUS TLV, Value = LOST
+
+       Figure 9: HELLO Message Generation: Advertisement of Formerly
+         Symmetric 1-Hop Neighbor on This MANET Interface as Lost
+
+   Figure 10 illustrates the time, with duration N_HOLD_TIME, during
+   which all network addresses of a formerly, but no longer, symmetric
+   1-hop neighbor, are advertised as LOST in HELLO messages on all MANET
+   interfaces using an OTHER_NEIGHB TLV (if not also reported using a
+   LINK_STATUS TLV) thus allowing all other symmetric 1-hop neighbors to
+   update their 2-Hop Sets accordingly.
+
+     L_HOLD_TIME:   |----------------------------|
+
+     Time:       ---*---------------------------------->
+                    ^                            ^
+                    |                            |
+         Formerly symmetric 1-hop neighbor       |
+         ceases to be symmetric                  |
+                                                 |
+                      Time up to which network addresses of
+                      this neighbor are advertised in HELLO
+                      messages on all MANET interfaces
+                      using an OTHER_NEIGHB TLV,
+                      Value = LOST
+
+      Figure 10: HELLO Message Generation: Advertisement of Formerly
+          Symmetric 1-Hop Neighbor on Any MANET Interface as Lost
+
+   Figure 11 illustrates the time, with duration I_HOLD_TIME, during
+   which a formerly, but no longer, used local interface network address
+   is excluded from being considered as a 2-hop neighbor network address
+   (in order that a router is not recorded as its own 2-hop neighbor
+   during that period).
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 78]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+     I_HOLD_TIME:      |----------------------------|
+
+     Time:          ---*----------------------------------->
+                       ^                            ^
+                       |                            |
+       Formerly used local interface                |
+       network address ceases to be                 |
+       assigned to a local interface                |
+                                                    |
+                               Time up to which this network
+                               address is excluded from being
+                               included in this router's 2-Hop Set
+
+            Figure 11: Local Interface Removed Network Address
+
+Appendix F.  Topology Pictures
+
+   This appendix illustrates various examples of physical topologies, as
+   well as how these are logically recorded by NHDP from the point of
+   view of the router A.  This representation is a composite of
+   information that would be contained within A's various Information
+   Bases after NHDP has been running for sufficiently long time for the
+   state to converge.
+
+   Note that the examples given in this appendix are NOT exhaustive, but
+   are selected to be illustrative of NHDP neighborhood representations
+   of physical MANET topologies.
+
+   The example topologies presented contain 3 physical routers A, B, and
+   C.   Each of these routers has one or two distinct interfaces,
+   denoted "top" and "bottom".  Each interface has one or two addresses,
+   and symmetric connectivity between a pair of interfaces is
+   illustrated by these being connected by a line.
+
+   In all examples, the topology is described as it is recorded by NHDP
+   in router A.
+
+F.1.  Example 1: Standard Single Interface Topology
+
+   In Figure 12, each router has a single interface, each with a single
+   IP address.  This is the simplest possible network, and the resulting
+   representation is given to the right in Figure 12.
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 79]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+         __________ __________
+        |          |          |
+       {1}        {2}        {3}
+        |          |          |              {1}--------{2}--------{3}
+     +--'--+    +--'--+    +--'--+
+     |  A  |    |  B  |    |  C  |
+     +-----+    +-----+    +-----+
+
+         Figure 12: Standard Single Interface Topology (Left), and
+                 Corresponding NHDP Representation (Right)
+
+   The Local Information Set in A contains a single Local Interface
+   Tuple that has an I_local_iface_addr_list of {1}.  This value is
+   denoted with a {1} on the leftmost part of the resulting
+   representation.
+
+   The Interface Information Base has only one Link Set, which
+   represents the "top" interface of A, or {1}.  This Link Set's only
+   Link Tuple has an L_neighbor_iface_addr_list containing {2}; this
+   corresponds to the dashed line from {1} to {2} to the right in
+   Figure 12.  The 2-Hop Set contains a single 2-Hop Tuple, with
+   N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3};
+   this corresponds to the dashed line from {2} to {3} to the right in
+   Figure 12.
+
+   The descriptions of the following examples in this appendix will be
+   derived similarly, and use the same notational conventions.
+
+F.2.  Example 2: Dual Addressed Interface on 1-Hop Neighbor
+
+   In Figure 13, the network is identical to that in Example 1, except
+   that the middle router, B, has two IP addresses on its single
+   interface.
+
+         __________ __________
+        |          |          |
+       {1}       {2,4}       {3}
+        |          |          |              {1}-------{2,4}-------{3}
+     +--'--+    +--'--+    +--'--+
+     |  A  |    |  B  |    |  C  |
+     +-----+    +-----+    +-----+
+
+      Figure 13: Single Interfaces, with 1-Hop Neighbor B Having Two
+      Addresses (Left), and Corresponding NHDP Representation (Right)
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 80]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   The content of the Interface Information Base is in this case
+   identical to Example 1, except that L_neighbor_iface_addr_list is
+   {2,4} and N2_neighbor_iface_addr_list is {2,4}.
+
+F.3.  Example 3: Dual Addressed Interface on 2-Hop Neighbor
+
+   In Figure 14, the network is identical to that in Example 1, except
+   that the rightmost router, C, has two IP addresses on its interface.
+
+         __________ __________
+        |          |          |
+       {1}        {2}       {3,4}                             +----{3}
+        |          |          |              {1}--------{2}---+
+     +--'--+    +--'--+    +--'--+                            +----{4}
+     |  A  |    |  B  |    |  C  |
+     +-----+    +-----+    +-----+
+
+      Figure 14: Single Interfaces, with 2-Hop Neighbor C Having Two
+      Addresses (Left), and Corresponding NHDP Representation (Right)
+
+   The content of the Interface Information Base is in this case
+   identical to than in Example 1, except that the 2-Hop Set contains an
+   extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and
+   N2_2hop_addr being {4}.  These two 2-Hop Tuples are illustrated by
+   the two lines from {2} to {3} and (2) to {4}, respectively.
+
+F.4.  Example 4: Dual Addressed Interfaces
+
+   In Figure 15, the network is identical to that in Example 1, except
+   that all routers have two IP addresses on their interface.  The Local
+   Information Base in router A is the same as in Example 1, except that
+   I_local_iface_addr_list is {1,5}.
+
+         __________ __________
+        |          |          |
+      {1,5}      {2,6}      {3,4}                             +----{3}
+        |          |          |             {1,5}------{2,6}--+
+     +--'--+    +--'--+    +--'--+                            +----{4}
+     |  A  |    |  B  |    |  C  |
+     +-----+    +-----+    +-----+
+
+      Figure 15: Single interfaces, all routers having two addresses
+           (left), and corresponding NHDP representation (right)
+
+   The content of the Interface Information Base is in this case a
+   combination of the Interface Information Bases from Examples 1, 2,
+   and 3.
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 81]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+F.5.  Example 5: Dual Interface on 2-Hop Neighbor
+
+   In Figure 16, all routers have a single IP address on each interface,
+   and with the 2-hop neighbor having two interfaces.
+
+         __________ __________
+        |          |          |
+       {1}        {2}        {3}                              +----{3}
+        |          |          |              {1}--------{2}---+
+     +--'--+    +--'--+    +-----+                            +----{4}
+     |  A  |    |  B  |    |  C  |
+     +-----+    +-----+    +-----+
+                              |
+                             {4}
+
+       Figure 16: Single Addresses, with 2-Hop Neighbor C Having Two
+     Interfaces (Left), and Corresponding NHDP Representation (Right)
+
+   The Interface Information Base is identical to that in Example 3;
+   NHDP does not distinguish topologically between this example and
+   Example 3.
+
+F.6.  Example 6: Dual interface on 1-Hop Neighbor
+
+   In Figure 17, all routers have a single IP address on each interface,
+   and with the 1-hop neighbor having two interfaces.
+
+         __________
+        |          |
+       {1}        {2}                                  +-----+
+        |          |                         {1}-------| {2} |------{4}
+     +--'--+    +--'--+    +-----+                     | {5} |
+     |  A  |    |  B  |    |  C  |                     +-----+
+     +-----+    +-----+    +-----+
+                   |          |
+                  {5}        {4}
+                   |__________|
+
+       Figure 17: Single Addresses, with 1-Hop Neighbor B Having Two
+     Interfaces (Left), and Corresponding NHDP Representation (Right)
+
+   The Local Information Base is identical to that in Example 1.
+
+   The Interface Information Base has only one Link Set containing one
+   Link Tuple with L_neighbor_iface_addr_list being {2}.  The 2-Hop Set
+   contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being
+   {2} and N2_2hop_addr being {4}.
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 82]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+   The Neighbor Information Base contains a Neighbor Set containing a
+   single Neighbor Tuple, which represents router B, with
+   N_neighbor_addr_list being {2,5}.  This entry is represented on the
+   right of Figure 17 by boxing {2} with {5}.
+
+   Note that router A does not have information indicating which of
+   router B's interfaces is connected to router C.  However, router A
+   knows that the address {4} (and thus router C) is reachable by using
+   {2} as next hop.
+
+F.7.  Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors
+
+   In Figure 18, all routers have a single IP address on each interface,
+   and both the 1-hop and 2-hop neighbors have two interfaces.
+   Furthermore, there are now two physical links between routers B and
+   C, over distinct interface pairs.
+
+         __________ __________
+        |          |          |
+       {1}        {2}        {3}                      +-----+   +----{3}
+        |          |          |             {1}-------| {2} |---+
+     +--'--+    +--'--+    +-----+                    | {5} |   +----{4}
+     |  A  |    |  B  |    |  C  |                    +-----+
+     +-----+    +-----+    +-----+
+                   |          |
+                  {5}        {4}
+                   |__________|
+
+    Figure 18: Single Addresses, with 1-Hop and 2-Hop Neighbors B and C
+    Having Two Interfaces (Left), and Corresponding NHDP Representation
+                                  (Right)
+
+   The Local Information Base is identical to that in Example 1.
+
+   The Link Set is identical to that in Example 6, and the 2-Hop Set
+   contains, as in Example 5 (and similarly to Examples 3 and 4), two
+   2-Hop Tuples representing the two links between routers B and C.
+
+   Note that router A does not have information describing which of
+   router B's interfaces is connected to which interfaces of router C,
+   or even that the interfaces with addresses {3} and {4} are interfaces
+   of the same router.  However, router A knows that the addresses {3}
+   and {4} (and thus router C) are reachable using {2} as next hop.
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 83]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+F.8.  Example 8: Dual Interface Locally and on 1-Hop Neighbor
+
+   In Figure 19, all routers have a single IP address on each interface,
+   and both A and its the 1-hop neighbor B have two interfaces.
+   Furthermore, there are now two physical links between routers A and
+   B, over distinct interface pairs.
+
+         __________ __________
+        |          |          |                       +-----+
+       {1}        {2}        {3}            {1}-------| {2} |--------{3}
+        |          |          |                       | {5} |
+     +--'--+    +--'--+    +-----+                    +-----+
+     |  A  |    |  B  |    |  C  |
+     +-----+    +-----+    +-----+                    +-----+
+        |          |                                  | {2} |
+       {6}        {5}                       {6}-------| {5} |--------{3}
+        |__________|                                  +-----+
+
+   Figure 19: Single Addresses, with Both A and 1-Hop Neighbor B Having
+   Two Interfaces (Left), and Corresponding NHDP Representation (Right)
+
+   The Local Information Set contains two Local Interface Tuples, with
+   I_local_iface_addr_list of {1} and {6}, respectively.
+
+   Each Interface Information Base's Link Set contains one Link Tuple,
+   representing the links between {1} and {2}, and between {6} and {5},
+   respectively.  The 2-Hop Set for interface {1} contains a single
+   2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and
+   N2_2hop_addr being {3}.  The 2-Hop Set for interface {6} contains a
+   single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and
+   N2_2hop_addr being {3}.
+
+   The Neighbor Information Base contains a Neighbor Set containing a
+   single Neighbor Tuple, which represents router B, with
+   N_neighbor_addr_list being {2,5}.  This entry is denoted by boxing
+   {2} with {5}.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 84]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+F.9.  Example 9: Dual Interface on All Routers
+
+   In Figure 20, all routers have a single IP address on each interface,
+   and all routers have two interfaces.  Furthermore, there are now two
+   physical links between A and B, over distinct interface pairs, and
+   two physical links between B and C, also over distinct interface
+   pairs.
+
+         __________ __________
+        |          |          |                       +-----+   +----{3}
+       {1}        {2}        {3}            {1}-------| {2} |---+
+        |          |          |                       | {5} |   +----{4}
+     +--'--+    +--'--+    +-----+                    +-----+
+     |  A  |    |  B  |    |  C  |
+     +-----+    +-----+    +-----+                    +-----+
+        |          |          |                       | {2} |   +----{3}
+       {6}        {5}        {4}            {6}-------| {5} |---+
+        |__________|__________|                       +-----+   +----{4}
+
+    Figure 20: Single Addresses, with All Routers Having Two Interfaces
+           (Left), and Corresponding NHDP Representation (Right)
+
+   The Local Information Set is identical to that in Example 8.  The
+   Interface Information Base for each interface in A is also identical
+   to that in Example 8, except that an additional 2-Hop Tuple is
+   present in each 2-Hop Set, each representing the link between router
+   B and the interface of router C with address {4}.
+
+   As in Example 7, router A does not have information describing which
+   of router B's interfaces is connected to which interface of C, or
+   even that the interfaces with addresses {3} and {4} are interfaces of
+   the same router.  However, router A knows that the addresses {3} and
+   {4} (and router C) are reachable by using {2} or {5} (depending on
+   via which of its local interfaces) as next hop.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 85]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+F.10.  Example 10: Dual Addressed Dual Interfaces on All Routers
+
+   In Figure 21, all routers have two IP addresses on each interface,
+   and all routers have two interfaces.  Furthermore, there are now two
+   physical links between A and B, over distinct interface pairs, and
+   two physical links between B and C, also over distinct interface
+   pairs.
+
+                                                                 +--{9}
+         __________ __________                            +------|
+        |          |          |                 +-----+   |      +--{10}
+      {1,2}      {5,6}      {9,10}       {1,2}--|{5,6}|---+
+        |          |          |                 |{7,8}|   |      +--{11}
+     +--'--+    +--'--+    +-----+              +-----+   +------|
+     |  A  |    |  B  |    |  C  |                               +--{12}
+     +-----+    +-----+    +-----+
+        |          |          |                                  +--{9}
+        |          |          |                 +-----+   +------|
+        |          |          |                 |{5,6}|   |      +--{10}
+      {3,4}      {7,8}     {11,12}       {3,4}--|{7,8}|---+
+        |__________|__________|                 +-----+   |      +--{11}
+                                                          +------|
+                                                                 +--{12}
+
+     Figure 21: Dual Addresses, with All Routers Having Two Interfaces
+           (Left) and Corresponding NHDP Representation (Right)
+
+   This example is the combination of all the preceding examples in this
+   appendix.  The Local Information Set in A contains Local Information
+   Tuples for each of its interfaces, and each Interface Information
+   Base contains in its Link Set a representation of links {1,2}-{5,6}
+   or {3,4}-{7,8}, respectively.  The Neighbor Set (in the Neighbor
+   Information Base) records the existence of router B and all of its
+   addresses on all its interfaces, i.e., {5,6,7,8}.
+
+   As in Example 9, each interface address of router C is represented in
+   the 2-Hop Set of each Interface Information Base as a link from
+   router B to each of these addresses.  Router A does not have
+   information describing which of router B's interfaces is connected to
+   which interface of C, nor that the addresses {9}, {10}, {11}, and
+   {12} are addresses of the same router (or that some of these, such as
+   {9} and {10}, are addresses on the same interface of the router).
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 86]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+F.11.  Example 11: Single Addressed Dual Interface Locally
+
+   In Figure 22, all routers have a single interface, except for router
+   A which has two.  Each of A's two interfaces has a link with the
+   single interface of router B.  All interfaces have a single address.
+
+         __________ __________
+        |     _____|          |
+       {1}   |    {2}        {3}             {1}--------{2}---------{3}
+        |    |     |          |
+     +--'--+ |  +--'--+    +-----+
+     |  A  | |  |  B  |    |  C  |
+     +-----+ |  +-----+    +-----+
+        |    |
+       {6}   |                               {6}--------{2}---------{3}
+        |____|
+
+      Figure 22: Single Addresses, with A Having Two Interfaces, Both
+    Linked to the Single Interface of B (Left), and Corresponding NHDP
+                          Representation (Right)
+
+   This is similar to Example 8, except that the single address {2} also
+   replaces the address {5}.  In particular, both Link Tuples (one in
+   each Link Set, each in its corresponding Interface Information Base)
+   have L_neighbor_iface_addr_list being {2}, the Neighbor Set (in the
+   Neighbor Information Base) contains a single Neighbor Tuple with
+   N_neighbor_addr_list being {2}, and both 2-Hop Tuples (one in each
+   2-Hop Set, each in its corresponding Interface Information Base) have
+   N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 87]
+
+RFC 6130                       MANET-NHDP                     April 2011
+
+
+Authors' Addresses
+
+   Thomas Heide Clausen
+   LIX, Ecole Polytechnique
+
+   Phone: +33 6 6058 9349
+   EMail: T.Clausen@computer.org
+   URI:   http://www.ThomasClausen.org/
+
+
+   Christopher Dearlove
+   BAE Systems ATC
+
+   Phone: +44 1245 242194
+   EMail: chris.dearlove@baesystems.com
+   URI:   http://www.baesystems.com/
+
+
+   Justin W. Dean
+   Naval Research Laboratory
+
+   Phone: +1 202 767 3397
+   EMail: jdean@itd.nrl.navy.mil
+   URI:   http://pf.itd.nrl.navy.mil/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clausen, et al.              Standards Track                   [Page 88]
+