GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc6130

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6130.txt · Last modified: 2011/04/06 00:12 (external edit)