Enhanced Interior Gateway Routing Protocol
draft-savage-eigrp-03

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2015-08-18 (latest revision 2015-08-17)
Stream ISE
Intended RFC status Informational
Formats plain text pdf html bibtex
IETF conflict review conflict-review-savage-eigrp
Stream ISE state In IESG Review
Consensus Boilerplate Unknown
Document shepherd Adrian Farrel
Shepherd write-up Show (last changed 2015-08-17)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to "Nevil Brownlee" <rfc-ise@rfc-editor.org>
IANA IANA review state IANA - Not OK
IANA action state None
Internet Engineering Task Force                                         D. Savage
Internet-Draft                                                              J. Ng
Intended status: Informational                                           S. Moore
Expires:   Febuary, 2016                                            Cisco Systems
                                                                         D. Slice
                                                                 Cumulus Networks
                                                                        P. Paluch
                                                             University of Zilina
                                                                         R. White
                                                                         Ericsson
                                                                      16 Aug 2015

                Enhanced Interior Gateway Routing Protocol
                       draft-savage-eigrp-03.txt

Abstract

This document describes the protocol design and architecture for
Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing
protocol based on Distance Vector technology. The specific algorithm
used is called DUAL, a Diffusing Update Algorithm [4]. The algorithm
and procedures were researched, developed, and simulated by SRI
International.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF).  Note that other groups may also distribute working
documents as Internet-Drafts.  The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on  Febuary 16, 2016.

Copyright Notice

Copyright (c) 2015 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 not be modified, and derivative works of it may not be
created, except to format it for publication as an RFC or to translate it into
languages other than English.

Savage, et al.                  Expires August 16, 2015                    [1]

Internet-Draft                          EIGRP                     August, 2015
 Table of Contents

 1 Introduction ........................................................ 5
 2 Terminology ......................................................... 5
 3 The DUAL Diffusing Update Algorithm ................................. 8
   3.1 Algorithm Description ........................................... 8
   3.2 Route States .................................................... 8
   3.3 Feasibility Condition ........................................... 9
   3.4 DUAL Message Types ............................................. 11
   3.5 DUAL Finite State Machine (FSM) ................................ 11
   3.6 DUAL Operation - Example Topology .............................. 15
 4 EIGRP Packets ...................................................... 17
   4.1 UPDATE Packets ................................................. 17
   4.2 QUERY Packets .................................................. 17
   4.3 REPLY Packets .................................................. 18
   4.4 Exception Handling ............................................. 18
     4.4.1 Active Duration (Stuck-in-Active) .......................... 18
       4.4.1.1 SIA-QUERY .............................................. 18
       4.4.1.2 SIA-REPLY .............................................. 19
 5 EIGRP Protocol Operation ........................................... 20
   5.1 Finite State Machine ........................................... 20
   5.2 Reliable Transport Protocol .................................... 20
     5.2.1 Bandwidth on Low-Speed Links ............................... 25
   5.3 Neighbor Discovery/Recovery .................................... 25
     5.3.1 Neighbor Hold Time ......................................... 26
     5.3.2 HELLO Packets .............................................. 26
     5.3.3 UPDATE Packets ............................................. 26
       5.3.3.1 NULL Update ............................................ 26
     5.3.4 Initialization Sequence .................................... 26
     5.3.5 Neighbor Formation ......................................... 27
     5.3.6 QUERY Packets During Neighbor Formation .................... 28
   5.4 Topology Table ................................................. 28
     5.4.7 Route Management ........................................... 28
       5.4.7.1 Internal Routes ........................................ 28
       5.4.7.2 External routes ........................................ 29
       5.4.7.3 Split Horizon and Poison Reverse ....................... 29
         5.4.7.3.1 Startup Mode ....................................... 30
         5.4.7.3.2 Advertising Topology Table Change .................. 30
         5.4.7.3.3 Sending a QUERY/UPDATE ............................. 30
   5.5 EIGRP Metric Coefficients ...................................... 30
     5.5.1 Coefficients K1 and K2 ..................................... 31
     5.5.2 Coefficient K3 ............................................. 31
     5.5.3 Coefficients K4 and K5 ..................................... 31
     5.5.4 Coefficient K6 ............................................. 31
       5.5.4.1 Jitter ................................................. 31
       5.5.4.2 Energy ................................................. 32
   5.6 EIGRP Metric Calculations ...................................... 32
     5.6.1 Classic Metrics ............................................ 32
       5.6.1.1 Classic Composite Formulation .......................... 32

Savage, et al.                  Expires August 16, 2015                    [2]

Internet-Draft                          EIGRP                     August, 2015

     5.6.2 Wide Metrics ............................................... 34
       5.6.2.1 Wide Metric Vectors .................................... 34
       5.6.2.2 Wide Metric Conversion Constants ....................... 35
       5.6.2.3 Throughput Calculation ................................. 35
       5.6.2.4 Latency Calculation .................................... 35
       5.6.2.5 Composite Calculation .................................. 36
 6 Security Considerations ............................................ 36
 7 IANA Considerations ................................................ 37
 8 References ......................................................... 37
   8.1 Normative References ........................................... 37
   8.2 Informative References ......................................... 37
 9 Acknowledgments .................................................... 38
 10 EIGRP Packet Formats .............................................. 39
   10.1 Protocol Number ............................................... 39
   10.2 Protocol Assignment Encoding .................................. 39
   10.3 Destination Assignment Encoding ............................... 39
   10.4 EIGRP Communities Attribute ................................... 40
   10.5 EIGRP Packet Header ........................................... 40
   10.6 EIGRP TLV Encoding Format ..................................... 42
     10.6.1 Type Field Encoding ....................................... 42
     10.6.2 Length Field Encoding ..................................... 42
     10.6.3 Value Field Encoding ...................................... 43
   10.7 EIGRP Generic TLV Definitions ................................. 43
     10.7.1 0x0001 - PARAMETER_TYPE ................................... 43
     10.7.2 0x0002 - AUTHENTICATION_TYPE .............................. 43
       10.7.2.1 0x02 - MD5 Authentication Type ........................ 44
       10.7.2.2 0x03 - SHA2 Authentication Type ....................... 44
     10.7.3 0x0003 - SEQUENCE_TYPE .................................... 44
     10.7.4 0x0004 - SOFTWARE_VERSION_TYPE ............................ 44
     10.7.5 0x0005 - MULTICAST_SEQUENCE_TYPE .......................... 44
     10.7.6 0x0006 - PEER_INFORMATION_TYPE ............................ 44
     10.7.7 0x0007 - PEER_TERMAINATION_TYPE ........................... 45
     10.7.8 0x0008 - TID_LIST_TYPE .................................... 45
   10.8 Classic Route Information TLV Types ........................... 45
     10.8.1 Classic Flag Field Encoding ............................... 45
     10.8.2 Classic Metric Encoding ................................... 46
     10.8.3 Classic Exterior Encoding ................................. 46
     10.8.4 Classic Destination Encoding .............................. 47
     10.8.5 IPv4 Specific TLVs ........................................ 48
       10.8.5.1 IPv4 INTERNAL_TYPE .................................... 48
       10.8.5.2 IPv4 EXTERNAL_TYPE .................................... 48
       10.8.5.3 IPv4 COMMUNITY_TYPE ................................... 49
     10.8.6 IPv6 Specific TLVs ........................................ 50
       10.8.6.1 IPv6 INTERNAL_TYPE .................................... 50
       10.8.6.2 IPv6 EXTERNAL_TYPE .................................... 50
       10.8.6.3 IPv6 COMMUNITY_TYPE ................................... 51
   10.9 Multi-Protocol Route Information TLV Types .................... 52
     10.9.1 TLV Header Encoding ....................................... 52
     10.9.2 Wide Metric Encoding ...................................... 53
     10.9.3 Extended Metrics .......................................... 54

Savage, et al.                  Expires August 16, 2015                    [3]

Internet-Draft                          EIGRP                     August, 2015

      10.9.3.1 0x00   NoOp ............................................ 54
      10.9.3.2 0x01   Scaled Metric ................................... 54
      10.9.3.3 0x02   Administrator Tag ............................... 55
      10.9.3.4 0x03   Community List .................................. 55
      10.9.3.5 0x04   Jitter .......................................... 55
      10.9.3.6 0x05   Quiescent Energy ................................ 56
      10.9.3.7 0x06   Energy .......................................... 56
      10.9.3.8 0x07   AddPath ......................................... 56
        10.9.3.8.1 Addpath with IPv4 Next-hop ......................... 56
       10.9.3.8.2 Addpath with IPv6 Next-hop .......................... 57
    10.9.4 Exterior Encoding .......................................... 58
    10.9.5 Destination Encoding ....................................... 58
    10.9.6 Route Information .......................................... 59
      10.9.6.1 INTERNAL TYPE .......................................... 59
      10.9.6.2 EXTERNAL TYPE .......................................... 59

Savage, et al.                  Expires August 16, 2015                    [4]

Internet-Draft                          EIGRP                     August, 2015

 1 Introduction
 This document describes the Enhanced Interior Gateway Routing Protocol (EIGRP),
 a routing protocol designed and developed by Cisco Systems. DUAL, the algorithm
 used to converge the control plane to a single set of loop free paths is based
 on research conducted at SRI International. The Diffusing Update Algorithm
 (DUAL) is the algorithm used to obtain loop-freedom at every instant throughout
 a route computation [3]. This allows all routers involved in a topology change
 to synchronize at the same time; the routers not affected by topology changes
 are not involved in the recalculation. This document describes the protocol that
 implements these functions.

 2 Terminology
 The following list describes acronyms and definitions for terms used throughout
 this document:

 ACTIVE State
     The local state of a route on a router triggered by any event that causes
 all neighbors providing the current least cost path to fail the Feasibility
 Condition check. A route in Active state is considered unusable. During Active
 state, the router is actively attempting to compute the least cost loop-free
 path by explicit coordination with its neighbors using Query and Reply messages.

 Address Family Identifier (AFI)
     Identity of the network layer network layer reachability information
 associated with the network layer reachability information being advertised [10].

 Autonomous System (AS)
     A collection of routers exchanging routes under the control of one or more
 network administrators on behalf of a single administrative entity.

 Base Topology
     A routing domain representing a physical (non-virtual) view of the network
 topology consisting of attached devices and network segments EIGRP uses to form
 neighbor relationships. Destinations exchanged within the Base Topology are
 identified with a Topology Identifier value of zero (0).

 Computed Distance (CD)
     Total distance (metric) along a path from the current router to
 a destination network through a particular neighbor computed using that
 neighbor's Reported Distance and the cost of the link between the two routers.
 Exactly one Computed Distance is computed and maintained per the [Destination,
 Advertising Neighbor] pair.

 Diffusing Computation
     A distributed computation in which a single starting node commences the
 computation by delegating subtasks of the computation to its neighbors that may
 in turn recursively delegate sub-subtasks further, including a signaling scheme
 allowing the starting node to detect that the computation has finished while
 avoiding false terminations. In DUAL, the task of coordinated updates of routing
 tables and resulting best path computation is performed as a diffusing
 computation.

 Diffusing Update Algorithm (DUAL)
     A loop-free routing algorithm used with distance vectors or link states that
 provides a diffused computation of a routing table. It works very well in the
 presence of multiple topology changes with low overhead. The technology was
 researched and developed at SRI International.

Savage, et al.                  Expires August 16, 2015                    [5]

Internet-Draft                          EIGRP                     August, 2015

 Downstream Router
     A router that is one or more hops away from the router in question in the
 direction of the destination.

 EIGRP
     Enhanced Interior Gateway Routing Protocol.

 Feasibility Condition
     The Feasibility Condition is a sufficient condition used by a router to
 verify whether a neighboring router provides a loop-free path to a destination.
 EIGRP uses the Source Node Condition described in [4] stating that a neighboring
 router meets the Feasibility Condition if the neighbor's Reported Distance is
 less than this router's Feasible Distance.

 Feasible Distance (FD)
     Defined as the lowest known total metric to a destination from the current
 router since the last transition from ACTIVE to PASSIVE state. Being effectively
 a record of the smallest known metric since the last time the network entered
 the PASSIVE state, the FD is not necessarily a metric of the current best path.
 Exactly one Feasible Distance is computed per destination network.

 Feasible Successor
     A neighboring router that meets the Feasibility Condition for a particular
 destination, hence providing a guaranteed loop-free path.

 Neighbor / Peer
     For a particular router, another router toward   which an EIGRP session, also
 known as adjacency, is established. The ability of   two routers to become
 neighbors depends on their mutual connectivity and   compatibility of selected
 EIGRP configuration parameters. Two neighbors with   interfaces connected to a
 common subnet are known as adjacent neighbors. Two   neighbors that are multiple
 hops apart are known as remote neighbors.

 PASSIVE state
     The local state of a route in which at least one neighbor providing the
 current least cost path passes Feasibility Condition check. A route in PASSIVE
 state is considered usable and not in need of a coordinated re-computation.

 Reachability Information (NLRI)
 Information a router uses to calculate the global routing table to make routing
 and forwarding decisions.

 Reported Distance (RD)
     For a particular destination, the value representing the router's distance
 to the destination as advertised in all messages carrying routing information.
 Reported Distance is not equivalent to the current distance of the router to the
 destination and may be different from it during the process of path re-
 computation. Exactly one Reported Distance is computed and maintained per
 destination network.

 Sub-Topology
     For a given Base Topology, a sub-topology is characterized by an independent
 set of router and links in a network for which EIGRP performs an independent
 path calculation. This allows each sub-topology to implement class-specific
 topologies to carry class specific traffic.

 Successor
     For a particular destination, a neighboring router that meets the
 Feasibility Condition and, at the same time, provides the least cost path.

Savage, et al.                  Expires August 16, 2015                    [6]

Internet-Draft                          EIGRP                     August, 2015

 Stuck In Active (SIA)
     A destination that has remained in the ACTIVE State in excess of a
 predefined time period at the local router (Cisco implements this as 3 minutes)

 Successor Directed Acyclic Graph (SDAG)
     For a particular destination, a graph defined by routing table contents of
 individual routers in the topology, such that nodes of this graph are the
 routers themselves, and a directed edge from router X to router Y exists if and
 only if router Y is router X's successor. After the network has converged, in
 the absence of topological changes, SDAG is a tree.

 Topology Change / Topology Change Event
     Any event that causes the Computed Distance for a destination through a
 neighbor to be added modified or removed. As an example, detecting a link cost
 change, receiving any EIGRP message from a neighbor advertising an updated
 neighbor's Reported Distance

 Topology Identifier (TID)
     A number that is used to mark prefixes as belonging to a specific sub-
 topology.

 Topology Table
     A data structure used by EIGRP to store information about every known
 destination including, but not limited to, network prefix/prefix length,
 Feasible Distance, Reported Distance of each neighbor advertising the
 destination, Computed Distance over the corresponding neighbor, and route state.

 Type, Length, Value (TLV)
     An encoding format for information elements used in EIGRP messages to
 exchange information Each TLV-formatted information element consists of three
 generic fields: Type identifying the nature of information carried in this
 element; Length describing the length of the entire TLV triplet; and Value
 carrying the actual information. The Value field may itself be internally
 structured; this depends on the actual type of the information element. This
 format allows for extensibility and backward compatibility.

 Upstream Router
     A router that is one or more hops away from the router in question, in the
 direction of the source of the information.

Savage, et al.                  Expires August 16, 2015                    [7]

Internet-Draft                          EIGRP                     August, 2015

 3 The DUAL Diffusing Update Algorithm
 The Diffusing Update Algorithm (DUAL) constructs least cost paths to all
 reachable destinations in a network consisting of nodes and edges (routers and
 links). DUAL guarantees that each constructed path is loop-free at every instant
 including periods of topology changes and network re-convergence. This is
 accomplished by all routers, which are affected by a topology change, computing
 the new best path in a coordinated (diffusing) way and using the Feasibility
 Condition to verify prospective paths for loop freedom. Routers that are not
 affected by topology changes are not involved in the recalculation. The
 convergence time with DUAL rivals that of any other existing routing protocol.

 3.1 Algorithm Description
 DUAL is used by EIGRP to achieve fast loop-free convergence with little
 overhead, allowing EIGRP to provide convergence rates comparable, and in some
 cases better than, most common link state protocols [8]. Only nodes that are
 affected by a topology change need to propagate and act on information about the
 topology change, allowing EIGRP to have good scaling properties, reduced
 overhead, and lower complexity than many other interior gateway protocols.

 Distributed routing algorithms are required to propagate information as well as
 coordinate information among all nodes in the network. Unlike basic Bellman-Ford
 distance vector protocols that rely on uncoordinated updates when a topology
 change occurs, DUAL uses a coordinated procedure to involve the affected part of
 the network into computing a new least cost path, known as a diffusing
 computation.
 A diffusing computation grows by querying additional routers for their current
 Reported Distance to the affected destination, and shrinks by receiving replies
 from them. Unaffected routers send replies immediately, terminating the growth
 of the diffusing computation over them. These intrinsic properties cause the
 diffusing computation to self-adjust in scope and terminate as soon as possible.

 One attribute of DUAL is its ability to control the point at which the diffusion
 of a route calculation terminates by managing the distribution of reachability
 information through the network. Controlling the scope of the diffusing process
 is accomplished by hiding reachability information through aggregation
 (summarization), filtering, or other means. This provides the ability to create
 effective failure domains within a single AS, and allows the network
 administrator to manage the convergence and processing characteristics of the
 network.

 3.2 Route States
 A route to a destination can be in one of two states, PASSIVE or ACTIVE. These
 states describe whether the route is guaranteed to be both loop-free and the
 shortest available (the PASSIVE state), or whether such guarantee cannot be
 given (the ACTIVE state). Consequently, in PASSIVE state, the router does not
 perform any route recalculation in coordination with its neighbors because no
 such recalculation is needed.

 In ACTIVE state, the router is actively involved in re-computing the least cost
 loop-free path in coordination with its neighbors. The state is reevaluated and
 possibly changed every time a topology change is detected. A topology change is
 any event that causes the Computed Distance to the destination over any neighbor
 to be added, changed, or removed from EIGRP's topology table.

Savage, et al.                  Expires August 16, 2015                    [8]

Internet-Draft                          EIGRP                     August, 2015

 More exactly, the two states are defined as follows:

    o Passive
      A route is considered in the Passive state when at least one neighbor that
 provides the current least total cost path passes the Feasibility Condition
 check that guarantees loop freedom. A route in the PASSIVE is usable and its
 next hop is perceived to be a downstream router.

    o Active
      A route is considered in the ACTIVE state if neighbors that do not pass the
 Feasibility Condition check provide lowest cost path, and therefore the path
 cannot be guaranteed loop free. A route in the ACTIVE state is considered
 unusable and this router must coordinate with its neighbors in the search for
 the new loop-free least total cost path.

 In other words, for a route to be in PASSIVE state, at least one neighbor that
 provides the least total cost path must be a Feasible Successor. Feasible
 Successors providing the least total cost path are also called Successors. For a
 route to be in PASSIVE state, at least one Successor must exist.

 Conversely, if the path with the least total cost is provided by routers that
 are not Feasible Successors (and thus not Successors), the route is in the
 ACTIVE state, requiring re-computation.

 Notably, for the definition of PASSIVE and ACTIVE states it does not matter if
 there are Feasible Successors providing a worse-than-least total cost path.
 While these neighbors are guaranteed to provide a loop free path, that path is
 potentially not the shortest available.

 The fact that the least total cost path can be provided by a neighbor that fails
 the Feasibility Condition check may not be intuitive. However, such situation
 can occur during topology changes when the current least total cost path fails,
 and the next least total cost path traverses a neighbor that is not a Feasible
 Successor.

 While a router has a route in the ACTIVE state, it must not change its Successor
 (i.e. modify the current SDAG), nor modify its own Feasible Distance or Reported
 Distance until the route enters the PASSIVE state again. Any updated information
 about this route received during ACTIVE state is reflected only in Computed
 Distances. Any updates to the Successor, Feasible Distance and Reported Distance
 are postponed until the route returns to PASSIVE state. The state transitions
 from PASSIVE to ACTIVE and from ACTIVE to PASSIVE are controlled by the DUAL FSM
 and are described in detail in Section 3.5.

 3.3 Feasibility Condition
 The Feasibility Condition is a criterion used to verify loop freedom of a
 particular path. The Feasibility Condition is a sufficient but not a necessary
 condition, meaning that every path meeting the Feasibility Condition is
 guaranteed to be loop-free; however, not all loop-free paths meet the
 Feasibility condition.
 The Feasibility Condition is used as an integral part of DUAL operation: Every
 path selection in DUAL is subject to the Feasibility Condition check. Based on
 the result of the Feasibility Condition check after a topology change is
 detected, the route may either remain PASSIVE (if, after the topology change,
 the neighbor providing the least cost path meets the Feasibility Condition) or
 it needs to enter the ACTIVE state (if the topology change resulted in none of
 the neighbors providing the least cost path to meet the Feasibility Condition).

Savage, et al.                  Expires August 16, 2015                    [9]

Internet-Draft                          EIGRP                     August, 2015

 The Feasibility Condition is a part of DUAL that allows the diffused computation
 to terminate as early as possible. Nodes that are not affected by the topology
 change are not required to perform a DUAL computation and may not be aware a
 topology change occurred. This can occur in two cases;

 First, if informed about a topology change, a router may keep a route in PASSIVE
 State if it is aware of other paths that are downstream towards the destination
 (routes meeting the Feasibility Condition). A route that meets the Feasibility
 Condition is determined to be loop-free and downstream along the path between
 the router and the destination.

 Second, if informed about a topology change for which it does not currently have
 reachability information, a router is not required to enter into the ACTIVE
 state, nor is it required to participate in the DUAL process.

 In order to facilitate describing the Feasibility Condition, a few definitions
 are in order.

     o A Successor for a given route is the next-hop used to forward data traffic
 for a destination. Typically the successor is chosen based on the least cost
 path to reach the destination.

     o A Feasible Successor is a neighbor that meets the Feasibility Condition. A
 Feasible Successor is regarded as a downstream neighbor towards the destination
 but it may not be the least cost path, but could still be used for forwarding
 data packets in the event equal or unequal cost load sharing was active. A
 Feasible Successor can become a successor when the current successor becomes
 unreachable.

     o The Feasibility Condition is met when a neighbor's advertised cost, (RD)
 to a destination is less than the Feasible Distance for that destination, or in
 other words, the Feasibility Condition is met when the neighbor is closer to the
 destination than the router itself has ever been since the destination has
 entered the PASSIVE state for the last time.

     o The Feasible Distance is the lowest distance to the destination since the
 last time the route went from ACTIVE to PASSIVE state. It should be noted it is
 not necessarily the current best distance - rather, it is a historical record of
 the best distance known since the last diffusing computation for the destination
 has finished. Thus, the value of the Feasible Distance can either be the same as
 the current best distance, or it can be lower.

 A neighbor that advertises a route with a cost that does not meet the
 Feasibility Condition may be upstream and thus cannot be guaranteed to be the
 next hop for a loop free path. Routes advertised by upstream neighbors are not
 recorded in the routing table but saved in the topology table.

Savage, et al.                  Expires August 16, 2015                    [10]

Internet-Draft                          EIGRP                     August, 2015

 3.4 DUAL Message Types
 The DUAL algorithm operates with three basic message types, QUERY, UPDATE, and
 REPLY:

     o UPDATE - sent to indicate a change in metric or an addition of a
 destination.

     o QUERY - sent when Feasibility Condition fails which can happen for reasons
 like a destination becoming unreachable, or the metric increasing to a value
 greater than its current Feasible Distance.

     o REPLY - sent in response to a QUERY or SIA-QUERY

 In addition to these 3 basic types, two addition sub-types have been added to
 EIGRP:

     o SIA-QUERY - sent when a REPLY has not been received within one half the
 SIA interval (90 seconds as implemented by Cisco)

     o SIA-REPLY - sent in response to an SIA-QUERY indicating the route is still
 in ACTIVE state. This response does not stratify the original QUERY, but is
 only used to indicate the sending neighbor is still in the ACTIVE State for the
 given destination.

 When in the PASSIVE State, a received QUERY may be propagated if there is no
 Feasible Successor found. If a Feasible Successor is found, the QUERY is not
 propagated and a REPLY is sent for the destination with a metric equal to the
 current routing table metric. When a QUERY is received from a non-successor in
 ACTIVE State a REPLY is sent and the QUERY is not propagated. The REPLY for the
 destination contains a metric equal to the current routing table metric.

 3.5 DUAL Finite State Machine (FSM)
 The DUAL finite state machine embodies the decision process for all route
 computations. It tracks all routes advertised by all neighbors. The distance
 information, known as a metric, is used by DUAL to select efficient loop free
 paths. DUAL selects routes to be inserted into a routing table based on Feasible
 Successors. A successor is a neighboring router used for packet forwarding that
 has least cost path to a destination that is guaranteed not to be part of a
 routing loop.
 When there are no Feasible Successors but there are neighbors advertising the
 destination, a recalculation must occur to determine a new successor.

 The amount of time it takes to calculate the route impacts the convergence time.
 Even though the recalculation is not processor-intensive, it is advantageous to
 avoid recalculation if it is not necessary. When a topology change occurs, DUAL
 will test for Feasible Successors. If there are Feasible Successors, it will use
 any it finds in order to avoid any unnecessary recalculation.

 The finite state machine, which applies per destination in the topology table,
 operates independently for each destination. It is true that if a single link
 goes down, multiple routes may go into ACTIVE State. However, a separate
 Successor Directed Acyclic Graph (SDAG) is computed for each destination, so
 loop-free topologies can be maintained for each reachable destination.

Savage, et al.                  Expires August 16, 2015                    [11]

Internet-Draft                          EIGRP                     August, 2015
 Figure 1 illustrates the FSM:

  i   Node that is computing route.
  j   Destination node or network.
  K   Any neighbor of node i.
  oij QUERY origin flag
    0 = metric increase during ACTIVE State
    1 = node i originated
    2 = QUERY from, or link increase to, successor during ACTIVE State
    3 = QUERY originated from successor.
  rijk REPLY status flag for each neighbor k for destination j,
    1 = awaiting REPLY,
    0 = received REPLY.
  lik = the link connecting node i to neighbor k.

                +------------+                            +-----------+
                |               \                       /              |
                |                 \                   /                |
                |   +=================================+                |
                |   |                                              |   |
                |(1)|                   Passive                    |(2)|
                +-->|                                              |<--+
                    +=================================+
                         ^      |         ^      ^      ^      |
                    (14)|       |(15)|           |(13)|        |
                         | (4)|           |(16)|        | (3)|
                         |      |         |      |      |      +------------+
                         |      |         |      |      |                       \
               +-------+        +         +      |      +-------------+           \
             /                /         /        |                        \         \
           /                /         /          +----+                     \         \
         |                  |       |                   |                     |         |
         |                  v       |                   |                     |         v
    +==========+(11) +==========+                   +==========+(12) +==========+
    | Active |---->| Active |(5) | Active |---->| Active |
    |              | (9)|                   |---->|               | (10)|                 |
    | Oij=0        |<----| Oij=1            |       | Oij=2       |<----| Oij=3           |
 +--|              | +--|                   | +--|                | +--|                  |
 | +==========+ | +==========+ | +==========+ | +==========+
 |       ^      |(5) |        ^                |      ^      ^       |              ^
 |       |      +-----|------|---------|----+                |       |              |
 +------+             +------+                 +---------+           +---------+
 (6,7,8)              (6,7,8)                      (6,7,8)             (6,7,8)

                     Figure 1 - DUAL Finite State Machine

Savage, et al.                  Expires August 16, 2015                    [12]

Internet-Draft                          EIGRP                     August, 2015

 The following describes in detail the state/event/action transitions of the DUAL
 FSM. For all steps, the topology table is updated with the new metric
 information from either; QUERY, REPLY, or UPDATE received.

 (1) A QUERY is received from a neighbor that is not the current successor. The
 route is currently in Passive State. As the Successor is not affected by the
 QUERY, and a Feasible Successor exists, the route remains in PASSIVE State.
 Since a Feasible Successor exists, a REPLY MUST be sent back to the originator
 of the QUERY. Any metric received in the QUERY from that neighbor is recorded in
 the topology table and FC is run to check for any change to current successor.

 (2) A directly connected interface changes state (connects, disconnects, or
 changes metric), or similarly an UPDATE or QUERY has been received with a metric
 change for an existing destination, the route will stay in the Active State if
 the current successor is not affected by the change, or it is no longer
 reachable and there is a Feasible Successor. In either case, an UPDATE is sent
 with the new metric information if it has changed.

 (3) A QUERY was received from a neighbor who is the current successor and no
 Feasible Successors exist. The route for the destination goes into ACTIVE State.
 A QUERY is sent to all neighbors on all interfaces that are not split horizon.
 Split horizon takes effect for a query
 or update from the successor it is using for the destination in the
 query. The QUERY origin flag is set to indicate the QUERY originated from a
 neighbor marked as successor for route. The REPLY status flag is set for all
 neighbors to indicate outstanding replies.

 (4) A directly connected link has gone down or its cost has increased, or an
 UPDATE has been received with a metric increase. The route to the destination
 goes to ACTIVE State if there are no Feasible Successors found. A QUERY is sent
 to all neighbors on all interfaces. The QUERY origin flag is to indicate that
 the router originated the QUERY. The REPLY status flag is set to 1 for all
 neighbors to indicate outstanding replies.

 (5) While a route for a destination is in ACTIVE State, and a QUERY is   received
 from the current successor, the route remains active. The QUERY origin   flag is
 set to indicate that there was another topology change while in ACTIVE   State.
 This indication is used so new Feasible Successors are compared to the   metric
 which made the route go to ACTIVE State with the current successor.

 (6) While a route for a destination is in ACTIVE State and a QUERY is received
 from a neighbor that is not the current successor, a REPLY should be sent to the
 neighbor. The metric received in the QUERY should be recorded.

 (7) If a link cost changes, or an UPDATE with a metric change is received in
 ACTIVE State from a non-successor, the router stays in ACTIVE State for the
 destination. The metric information in the UPDATE is recorded. When a route is
 in the ACTIVE State, neither a QUERY nor UPDATE are ever sent.

 (8) If a REPLY for a destination, in ACTIVE State, is received from a neighbor
 or the link between a router and the neighbor fails, the router records that the
 neighbor replied to the QUERY. The REPLY status flag is set to 0 to indicate
 this. The route stays in ACTIVE State if there are more replies pending because
 the router has not heard from all neighbors.

 (9) If a route for a destination is in ACTIVE State, and a link fails or a cost
 increase occurred between a router and its successor, the router treats this
 case like it has received a REPLY from its successor. When this occurs after the
 router originates a QUERY, it sets QUERY origin flag to indicate that another

Savage, et al.                  Expires August 16, 2015                    [13]

Internet-Draft                          EIGRP                     August, 2015

 topology change occurred in ACTIVE State.

 (10) If a route for a destination is in ACTIVE State, and a link fails or a cost
 increase occurred between a router and its successor, the router treats this
 case like it has received a REPLY from its successor. When this occurs after a
 successor originated a QUERY, the router sets the QUERY origin flag to indicate
 that another topology change occurred in ACTIVE State.

 (11) If a route for a destination is in ACTIVE State, the cost of the link
 through which the successor increases, and the last REPLY was received from all
 neighbors, but there is no Feasible Successor, the route should stay in ACTIVE
 State. A QUERY is sent to all neighbors. The QUERY origin flag is set to 1.

 (12) If a route for a destination is in ACTIVE State because of a QUERY received
 from the current successor, and the last REPLY was received from all neighbors,
 but there is no Feasible Successor, the route should stay in ACTIVE State. A
 QUERY is sent to all neighbors. The QUERY origin flag is set to 3.

 (13) Received replies from all neighbors. Since the QUERY origin flag indicates
 the successor originated the QUERY, it transitions to PASSIVE State and sends a
 REPLY to the old successor.

 (14) Received replies from all neighbors. Since the QUERY origin flag indicates
 a topology change to the successor while in ACTIVE State, it need not send a
 REPLY to the old successor. When the Feasibility Condition is met, the route
 state transitions to passive.

 (15) Received replies from all neighbors. Since the QUERY origin flag indicates
 either the router itself originated the QUERY or FC was not satisfied with the
 replies received in ACTIVE state, FD is reset to infinite value and the minimum
 of all the reported metrics is chosen as FD and route transitions back to
 PASSIVE state. A REPLY is sent to the old-successor if Oij flags indicate that
 there was a QUERY from successor.

 (16) If a route for a destination is in ACTIVE State because of a QUERY received
 from the current successor or there was an increase in Distance while in ACTIVE
 state, the last REPLY was received from all neighbors, and a Feasible Successor
 exists for the destination, the route can go into PASSIVE State and a REPLY is
 sent to successor if Oij indicates that QUERY was received from successor.

Savage, et al.                  Expires August 16, 2015                    [14]
Internet-Draft                          EIGRP                     August, 2015
 3.6 DUAL Operation - Example Topology
 The following topology (Figure 2) will be used to provide an example of how DUAL
 is used to reroute after a link failure. Each node is labeled with its costs to
 destination N. The arrows indicate the successor (next-hop) used to reach
 destination N. The least cost path is selected.

                                 N
                                 |
                              (1)A ---<--- B(2)
                                 |         |
                                 ^         |
                                 |         |
                              (2)D ---<--- C(3)

                         Figure 2 - Stable Topology

 In the case where the link between A and D fails (Figure 3);

           N                                    N
           |                                    |
           A ---<--- B                          A ---<--- B
           |         |                          |          |
           X         |                          ^          |
           |         |                          |          |
           D ---<--- C                          D ---<--- C
             Q->                                       <-R
                               N
                               |
                            (1)A ---<--- B(2)
                                         |
                                         ^
                                         |
                            (4)D --->--- C(3)

                   Figure 3 - Link between A and D fails

 Only observing destination provided by node N, D enters the ACTIVE State and
 sends a QUERY to all its neighbors, in this case node C.
    C determines that it has a Feasible Successor and replies immediately with
 metric 3.
    C changes its old successor of D to its new single successor B and the route
 to N stays in PASSIVE State.
    D receives the REPLY and can transition out of ACTIVE State since it received
 replies from all its neighbors.
    D now has a viable path to N through C.
    D elects C as its successor to reach node N with a cost of 4.

 Notice that node A and B were not involved in the recalculation since they were
 not affected by the change.

 Let s consider the situation in Figure 4, where Feasible Successors may not
 exist. If the link between node A and B fails, B goes into ACTIVE State for
 destination N since it has no Feasible Successors.
 Node B sends a QUERY to node C. C has no Feasible Successors, so it goes active
 for destination N and sends QUERY to B. B replies to the QUERY since it is in
 ACTIVE State.

Savage, et al.                  Expires August 16, 2015                    [15]

Internet-Draft                          EIGRP                     August, 2015

 Once C has received this REPLY, it has heard from all its neighbors, so it can
 go passive for the unreachable route. As C removes the (now unreachable)
 destination from its table, C sends REPLY to its old successor. B receives this
 REPLY from C, and determines this is the last REPLY it is waiting on before
 determining what the new state of the route should be; on receiving this REPLY,
 B deletes the route to N from its routing table.

 Since B was the originator of the initial QUERY it does not have to send a REPLY
 to its old successor (it would not be able to any ways, because the link to its
 old successor is down). Note that nodes A and D were not involved in the
 recalculation since their successors were not affected.

           N                              N
           |                              |
        (1)A ---<--- B(2)                 A ------- B   Q
           |         |                    |         |   |^      ^
           ^         ^                    ^         |   v|      |
           |         |                    |         |      |    |
        (2)D         C(3)                 D         C     ACK   R

                                Figure 4
         No Feasible Successors when link between A and B fails

Savage, et al.                  Expires August 16, 2015                    [16]

Internet-Draft                          EIGRP                     August, 2015

4 EIGRP Packets
 EIGRP uses 5 different packet types to handle session management and pass DUAL
 Message types:

     HELLO Packets (includes ACK)
     QUERY Packets (includes SIA-Query)
     REPLY Packets (includes SIA-Reply)
     REQUEST Packets
     UPDATE Packets

 EIGRP packets are directly encapsulated into a network layer protocol, such as
 IPv4 or IPv6. While EIGRP is capable of using additional encapsulation (such as
 AppleTalk, IPX, etc) no further encapsulation is specified in this draft.

 Support for network layer protocol fragmentation is not supported, and EIGRP
 will attempt to avoid a maximum size packets that exceed the interface MTU by
 sending multiple packets which are less than or equal to MTU sized packets.

 Each packet transmitted will use either multicast or unicast network layer
 destination addresses. When multicast addresses are used a mapping for the data
 link multicast address (when available) must be provided. The source address
 will be set to the address of the sending interface, if applicable. The
 following network layer multicast addresses and associated data link multicast
 addresses will be used.

     IPv4 - 224.0.0.10
     IPv6 - FF02:0:0:0:0:0:0:A

 The above data link multicast addresses will be used on multicast capable media,
 and will be media independent for unicast addresses. Network layer addresses
 will be used and the mapping to media addresses will be achieved by the native
 protocol mechanisms.

 4.1 UPDATE Packets
 UPDATE packets carry the DUAL UPDATE message type, and are used to convey
 information about destinations and the reachability of those destinations. When
 a new neighbor is discovered, unicast UPDATE packets are used to transmit a full
 table to the new neighbor, so the neighbor can build up its topology table. In
 normal operation (other than neighbor startup such as a link cost changes),
 UPDATE packets are multicast. UPDATE packets are always transmitted reliably.
 Each TLV destination will be processed individually through the DUAL state
 machine.

 4.2 QUERY Packets
 A QUERY packet carries the DUAL QUERY message type and is sent by a router to
 advertise that a route is in ACTIVE State and the originator is requesting
 alternate path information from its neighbors. An infinite metric is encoded by
 setting the Delay part of the metric to its maximum value.

 If there is a topology change that causes multiple destinations to be marked
 ACTIVE, EIGRP will build a single QUERY packet with all destinations present.
 The state of each route is recorded individually, so a responding QUERY or REPLY
 need not contain all the same destinations in a single packet. Since EIGRP uses
 a reliable transport mechanism, route QUERY packets are also guaranteed be
 reliably delivered.

 When a QUERY packet is received, each destination will trigger a DUAL event and

Savage, et al.                  Expires August 16, 2015                    [17]

Internet-Draft                          EIGRP                     August, 2015

the state machine will run individually for each route. Once the entire original
 QUERY packet is processed, then a REPLY or SIA-REPLY will be sent with the
 latest information.

 4.3 REPLY Packets
 A REPLY packet carries the DUAL REPLY message type and will be sent in response
 to a QUERY or SIA-QUERY packet. The REPLY packet will include a TLV for each
 destination and the associated vector metric in its own topology table.

 The REPLY packet is sent after the entire received QUERY packet is processed.
 When a REPLY packet is received, there is no reason to process the packet before
 an acknowledgment is sent. Therefore, an acknowledgment is sent immediately and
 then the packet is processed. The sending of the acknowledgement is accomplished
 either by sending an ACK packet, or piggybacked the acknowledgment onto another
 packet already being transmitted.

 Each TLV   destination will be processed individually through the DUAL state
 machine.   When a QUERY is received for a route that doesn t exist in our topology
 table, a   REPLY with infinite metric is sent and an entry in the topology table
 is added   with the metric in the QUERY if the metric is not an infinite value.

 4.4 Exception Handling

 4.4.1 Active Duration (Stuck-in-Active)
 When an EIGRP router transitions to ACTIVE state for a particular destination a
 QUERY is sent to a neighbor and the ACTIVE timer is started to limit the amount
 of time a destination may remain in an ACTIVE State.

 A route is regarded as Stuck-In-Active (SIA) when it does not receive a REPLY
 within a preset time. This time interval is broken into two equal periods
 following the QUERY, and up to 3 additional  busy  periods in which an SIA-QUERY
 packet is sent for the destination.

 This process is begun when a router sends a QUERY to its neighbor. After one
 half the SIA time interval (default implementation is 90 seconds), the router
 will send an SIA-QUERY; this must be replied to with either a REPLY or SIA-
 REPLY. Any neighbor which fails to send either a REPLY or SIA-REPLY with-in one-
 half the SIA interval will result in the neighbor being deemed to be  stuck  in
 the active state.

 If the SIA state is declared, DUAL may take one of two actions;
     a) Delete the route from that neighbor, acting as if the neighbor had
 responded with an unreachable REPLY message from the neighbor.

     b) Delete all routes from that neighbor and reset the adjacency with that
 neighbor, acting as if the neighbor had responded with an unreachable message
 for all routes.

 Implementation note: Cisco currently implements option  B.

 4.4.1.1 SIA-QUERY
 When a QUERY is still outstanding and awaiting a REPLY from a neighbor, there is
 insufficient information to determine why a REPLY has not been received. A lost
 packet, congestion on the link, or a slow neighbor could cause a lack of REPLY
 from a downstream neighbor.

 In order to attempt to ascertain if the neighboring device is still attempting

Savage, et al.                  Expires August 16, 2015                    [18]

Internet-Draft                          EIGRP                     August, 2015

 to converge on the active route, EIGRP may send an SIA-QUERY packet to the
 active neighbor(s). This enables an EIGRP router to determine if there is a
 communication issue with the neighbor, or it is simply still attempting to
 converge with downstream routers.

 By sending an SIA-QUERY, the originating router may extend the effective active
 time by resetting the ACTIVE timer which has been previously set, thus allowing
 convergence to continue so long as neighbor devices successfully communicate
 that convergence is still underway.

 The SIA-QUERY packet SHOULD be sent on a per-destination basis at one-half of
 the ACTIVE timeout period. Up to three SIA-QUERY packets for a specific
 destination may be sent, each at a value of one-half the ACTIVE time, so long as
 each are successfully acknowledged and met with an SIA-REPLY.

 Upon receipt of an SIA-QUERY packet, and EIGRP router should first send an ACK
 and then continue to process the SIA-QUERY information. The QUERY is sent on a
 per-destination basis at approximately one-half the active time.

 If the EIGRP router is still active for the destination specified in the SIA-
 QUERY, the router should respond to the originator with the SIA-REPLY indicating
 that active processing for this destination is still underway by setting the
 ACTIVE flag in the packet upon response.

 If the router receives an SIA-QUERY referencing a destination for which it has
 not received the original QUERY, the router should treat the packet as though it
 was a standard QUERY:

     1) Acknowledge the receipt of the packet
     2) Send a REPLY if a Successor exists
     3) If the QUERY is from the successor, transition to the ACTIVE state if and
 only if feasibility-condition fails and send an SIA-REPLY with the ACTIVE bit
 set

 4.4.1.2 SIA-REPLY
 An SIA-REPLY packet is the corresponding response upon receipt of an SIA-QUERY
 from an EIGRP neighbor. The SIA-REPLY packet will include a TLV for each
 destination and the associated metric for which is stored in its own routing
 table. The SIA-REPLY packet is sent after the entire received SIA-QUERY packet
 is processed.

 If the EIGRP router is still ACTIVE for a destination, the SIA-REPLY packet will
 be sent with the ACTIVE bit set. This confirms for the neighbor device that the
 SIA-QUERY packet has been processed by DUAL and that the router is still
 attempting to resolve a loop-free path (likely awaiting responses to its own
 QUERY to downstream neighbors).

 The SIA-REPLY informs the recipient that convergence is complete or still
 ongoing, however; it is an explicit notification that the router is still
 actively engaged in the convergence process. This allows the device that sent
 the SIA-QUERY to determine whether it should continue to allow the routes that
 are not converged to be in the ACTIVE state, or if it should reset the neighbor
 relationship and flush all routes through this neighbor.

Savage, et al.                  Expires August 16, 2015                    [19]

Internet-Draft                          EIGRP                     August, 2015

5 EIGRP Protocol Operation
 EIGRP has four basic components:
      o Finite State Machine
      o Reliable Transport Protocol
      o Neighbor Discovery/Recovery
      o Route Management

 5.1 Finite State Machine
 The detail of DUAL, the State Machine used by EIGRP, is covered in Section 3

 5.2 Reliable Transport Protocol
 The reliable transport is responsible for guaranteed, ordered delivery of EIGRP
 packets to all neighbors. It supports intermixed transmission of multicast or
 unicast packets. Some EIGRP packets must be transmitted reliably and others need
 not. For efficiency, reliability is provided only when necessary.

 For example, on a multi-access network that has multicast capabilities, such as
 Ethernet, it is not necessary to send HELLOs reliably to all neighbors
 individually. EIGRP sends a single multicast HELLO with an indication in the
 packet informing the receivers that the packet need not be acknowledged. Other
 types of packets, such as UPDATE packets, require acknowledgment and this is
 indicated in the packet. The reliable transport has a provision to send
 multicast packets quickly when there are unacknowledged packets pending. This
 helps insure that convergence time remains low in the presence of varying speed
 links.

 The DUAL Algorithm assumes there is lossless communication between devices and
 thus must rely upon the transport protocol to guarantee that messages are
 transmitted reliably. EIGRP implements the Reliable Transport Protocol to ensure
 ordered delivery and acknowledgement of any messages requiring reliable
 transmission. State variables such as a received sequence number, acknowledgment
 number, and transmission queues MUST be maintained on a per neighbor basis.

 The following sequence number rules must be met for the reliable EIGRP protocol
 to work correctly:

     o A sender of a packet includes its global sequence number
       in the sequence number field of the fixed header. The
       sender includes the receivers sequence number in the
       acknowledgment number field of the fixed header.
     o Any packets that do not require acknowledgment must be
       sent with a sequence number of 0.
     o Any packet that has an acknowledgment number of zero (0)
       indicates that sender is not expecting to explicitly
       acknowledging delivery. Otherwise, it is acknowledging
       a single packet.
     o Packets that are network layer multicast must contain
       acknowledgment number of 0.

 When a router transmits a packet, it increments its sequence number and marks
 the packet as requiring acknowledgment by all neighbors on the interface for
 which the packet is sent. When individual acknowledgments are unicast addressed
 by the receivers to the sender with the acknowledgment number equal to the
 packets sequence number, the sender SHALL clear the pending acknowledgement
 requirement for the packet from the respective neighbor.

Savage, et al.                  Expires August 16, 2015                    [20]

Internet-Draft                          EIGRP                     August, 2015

 If the required acknowledgement is not received for the packet, it MUST be
 retransmitted. Retransmissions will occur for a maximum of 5 seconds. This
 retransmission for each packet is tried 16 times after which if there is no ACK,
 the neighbor relationship is reset with that peer which didn t send the ACK.

 The protocol has no explicit windowing support. A receiver will acknowledge each
 packet individually and will drop packets that are received out of order.
 Duplicate packets are also discarded upon receipt. Acknowledgments are not
 accumulative. Therefore an ACK with a non-zero sequence number acknowledges a
 single packet.

 There are situations when multicast and unicast packets are transmitted close
 together on multi-access broadcast capable networks. The reliable transport
 mechanism MUST assure that all multicasts are transmitted in order as well as
 not mixing the order among unicasts and multicast packets. The reliable
 transport provides a mechanism to deliver multicast packets in order to some
 receivers quickly, while some receivers have not yet received all unicast or
 previously sent multicast packets. The SEQUENCE_TYPE TLV in HELLO packets
 achieves this. This will be explained in more detail in this section.

 Figure 5 illustrates the reliable transport protocol on point-to-point links.
 There are two scenarios that may occur, an UPDATE initiated packet exchange, or
 a QUERY initiated packet exchange.

 This example will assume no packet loss.

 Router A                         Router B
                 An UPDATE Exchange
                                    <----------------
                                    UPDATE (multicast)
 A receives packet                  SEQ=100, ACK=0
                                    Queues pkt on A s retransmit list
 ---------------->
 ACK (unicast)
 SEQ=0, ACK=100                     Receives ACK
 Process UPDATE                     Dequeue pkt from A s retransmit list

                 A QUERY Exchange
                                    <----------------
                                    QUERY (multicast)
 A receives packet                  SEQ=101, ACK=0
 Process QUERY                      Queues pkt on A s retransmit list

 ---------------->
 REPLY (unicast)
 SEQ=201, ACK=101                   Process ACK
                                    Dequeue pkt from A s retransmit list
                                    Process REPLY pkt
                                    <----------------
                                    ACK (unicast)
 A receives packet                  SEQ=0, ACK=201

       Figure 5 - Reliable Transfer on point-to-point links

Savage, et al.                  Expires August 16, 2015                    [21]

Internet-Draft                          EIGRP                     August, 2015

 The UPDATE exchange sequence requires UPDATE packets sent to be delivered
 reliably. The UPDATE packet transmitted contains a sequence number that is
 acknowledged by a receipt of an ACK packet. If the UPDATE or the ACK packet is
 lost on the network, the UPDATE packet will be retransmitted.

 Figure 6 illustrates the situation where there is heavy packet loss on a
 network.

 Router A                              Router B
                                       <----------------
                                       UPDATE (multicast)
 A receives packet                     SEQ=100, ACK=0
                                       Queues pkt on A s retransmit list
 ---------------->
 ACK (unicast)
 SEQ=0, ACK=100                        Receives ACK
 Process Update                        Dequeue pkt from A s retransmit list

                                       <--/LOST/--------------
                                       UPDATE (multicast)
                                       SEQ=101, ACK=0
                                       Queues pkt on A s retransmit list

                                       Retransmit Timer Expires
                                       <----------------
                                       Retransmit UPDATE (unicast)
                                       SEQ=101, ACK=0
                                       Keeps pkt on A s retransmit list
 ---------------->
 ACK (unicast)
 SEQ=0, ACK=101                        Receives ACK
 Process Update                        Dequeue pkt from A s retransmit list

                                 Figure 6
            Reliable Transfer on lossy point-to-point links

Savage, et al.                  Expires August 16, 2015                    [22]

Internet-Draft                          EIGRP                     August, 2015

Reliable delivery on multi-access LANs works in a similar fashion to point-to-
 point links. The initial packet is always multicast and subsequent
 retransmissions are unicast addressed. The acknowledgments sent are always
 unicast addressed. Figure 7 shows an example with 4 routers on an Ethernet.

         Router B -----------+
                             |
         Router C -----------+------------ Router A
                             |
         Router D -----------+

                          An UPDATE Exchange
                                       <----------------
                                       A send UPDATE (multicast)
                                       SEQ=100, ACK=0
                                       Queues pkt on B s retransmit list
                                       Queues pkt on C s retransmit list
                                       Queues pkt on D s retransmit list
 ---------------->
 B sends ACK (unicast)
 SEQ=0, ACK=100                        Receives ACK
 Process Update                        Dequeue pkt from B s retransmit list

 ---------------->
 C sends ACK (unicast)
 SEQ=0, ACK=100                        Receives ACK
 Process Update                        Dequeue pkt from C s retransmit list

 ---------------->
 D sends ACK (unicast)
 SEQ=0, ACK=100                        Receives ACK
 Process Update                        Dequeue pkt from D s retransmit list

                          A QUERY Exchange
                                       <----------------
                                       A send UPDATE (multicast)
                                       SEQ=101, ACK=0
                                       Queues pkt on B s retransmit list
                                       Queues pkt on C s retransmit list
                                       Queues pkt on D s retransmit list
 ---------------->
 B send REPLY (unicast)                <----------------
 SEQ=511, ACK=101                      A sends ACK (unicast to B)
 Process Update                        SEQ=0, ACK=511
                                       Dequeue pkt from B s retransmit list
 ---------------->
 C send REPLY (unicast)                <----------------
 SEQ=200, ACK=101                      A sends ACK (unicast to C)
 Process Update                        SEQ=0, ACK=200
                                       Dequeue pkt from C s retransmit list
 ---------------->
 D send REPLY (unicast)                <----------------
 SEQ=11, ACK=101                       A sends ACK (unicast to D)
 Process Update                        SEQ=0, ACK=11
                                       Dequeue pkt from D s retransmit list

                            Figure 7
              Reliable Transfer on Multi-Access Links

Savage, et al.                  Expires August 16, 2015                    [23]

Internet-Draft                          EIGRP                     August, 2015

 And finally, a situation where numerous multicast and unicast packets are sent
 close together in a multi-access environment is illustrated in Figure 9.

         Router B -----------+
                             |
         Router C -----------+------------ Router A
                             |
         Router D -----------+

                                    <----------------
                                    A send UPDATE (multicast)
                                    SEQ=100, ACK=0
 ---------------/LOST/->            Queues pkt on B s retransmit list
 B send ACK (unicast)               Queues pkt on C s retransmit list SEQ=0,
 ACK=100                     Queues pkt on D s retransmit list

 ---------------->
 C sends ACK (unicast)
 SEQ=0, ACK=100                     Dequeue pkt from C s retransmit list

 ---------------->
 D sends ACK (unicast)
 SEQ=0, ACK=100                     Dequeue pkt from D s retransmit list
                                    <----------------
                                    A send HELLO (multicast)
                                    SEQ=101, ACK=0, SEQ_TLV listing B

 B receives Hello, does not set CR-Mode
 C receives Hello, sets CR-Mode
 D receives Hello, sets CR-Mode
                                    <----------------
                                    A send UPDATE (multicast)
                                    SEQ=101, ACK=0, CR-Flag=1
 ---------------/LOST/->            Queues pkt on B s retransmit list
 B send ACK (unicast)               Queues pkt on C s retransmit list SEQ=0,
 ACK=100                     Queues pkt on D s retransmit list

 B ignores UPDATE 101 because CR-Flag
 is set and it is not in CR-Mode

 ---------------->
 C sends ACK (unicast)
 SEQ=0, ACK=101

 ---------------->
 D sends ACK (unicast)
 SEQ=0, ACK=101
                                    <----------------
                                    A resends UPDATE (unicast to B)
                                    SEQ=100, ACK=0
 B Packet duplicate
 --------------->
 B sends ACK (unicast)              A removes pkt from retransmit list
 SEQ=0, ACK=100
                                    <----------------
                                    A resends UPDATE (unicast to B)
                                    SEQ=101, ACK=0
 --------------->
 B sends ACK (unicast)              A removes pkt from retransmit list
 SEQ=0, ACK=101

Savage, et al.                  Expires August 16, 2015                    [24]

Internet-Draft                          EIGRP                     August, 2015

                            Figure 9

 Initially Router-A sends a multicast addressed UPDATE packet on the LAN. B and C
 receive it and send acknowledgments. Router-B receives the UPDATE but the
 acknowledgment sent is lost on the network. Before the retransmission timer for
 Router-B s packet expires, there is an event that causes a new multicast
 addressed UPDATE to be sent.

 Router-A detects that there is at least one neighbor on the interface with a
 full queue. Therefore, it MUST signal that neighbor to not receive the next
 packet or it would receive the retransmitted packet out of order.

 Router-A builds a HELLO packet with a SEQUENCE_TYPE TLV indicating all the
 neighbors that have full queues. In this case, the only neighbor address in the
 list is Router-B. The HELLO packet is sent via multicast unreliably out the
 interface.

 Router-C and Router-D process the SEQUENCE_TYPE TLV by looking for its own
 address in the list. If not found, they put themselves in Conditionally Received
 (CR-mode) mode.

 Router-B does not find its address in the SEQUENCE TLV peer list, so it enters
 CR-mode. Packets received by Router-B with the CR-flag MUST be discarded and not
 acknowledged.

 Later, Router-A will unicast transmit both packets 100 and 101 directly to
 Router-B. Router-B already has 100 so it discards and acknowledges it.

 Router-B then accepts and acknowledges packet 101. Once an acknowledgement is
 received, Router-A can remove both packets off Router-B s transmission list.

 5.2.1 Bandwidth on Low-Speed Links
 By default, EIGRP limits itself to using no more than 50% of the bandwidth
 reported by an interface when determining packet-pacing intervals. If the
 bandwidth does not match the physical bandwidth (the network architect may have
 put in an artificially low or high bandwidth value to influence routing
 decisions), EIGRP may:

    1. Generate more traffic than the interface can handle, possibly causing
 drops, thereby impairing EIGRP performance.

    2. Generate a lot of EIGRP traffic that could result in little bandwidth
 remaining for user data. To control such transmissions an interface-pacing timer
 is defined for the interfaces on which EIGRP is enabled. When a pacing timer
 expires, a packet is transmitted out on that interface.

 5.3 Neighbor Discovery/Recovery
 Neighbor Discovery/Recovery is the process that routers use to dynamically learn
 of other routers on their directly attached networks. Routers MUST also discover
 when their neighbors become unreachable or inoperative. This process is achieved
 with low overhead by periodically sending small HELLO packets. As long as any
 packets are received from a neighbor, the router can determine that neighbor is
 alive and functioning. Only after a neighbor router is considered operational
 can the neighboring routers exchange routing information.

Savage, et al.                  Expires August 16, 2015                    [25]

Internet-Draft                          EIGRP                     August, 2015

 5.3.1 Neighbor Hold Time
 Each router keeps state information about adjacent neighbors. When newly
 discovered neighbors are learned the address, interface, and hold time of the
 neighbor is noted. When a neighbor sends a HELLO, it advertises its Hold Time.
 The Hold Time is the amount of time a router treats a neighbor as reachable and
 operational. In addition to the HELLO packet, if any packet is received within
 the hold time period, then the Hold Time period will be rest. When the Hold Time
 expires, DUAL is informed of the topology change.

 5.3.2 HELLO Packets
 When an EIGRP router is initialized, it will start sending HELLO packets out any
 interface on which EIGRP is enabled. HELLO packets, when used for neighbor
 discovery, are normally sent multicast addressed. The HELLO packet will include
 the configured EIGRP metric K-values. Two routers become neighbors only if the
 K-values are the same. This enforces that the metric usage is consistent
 throughout the Internet. Also included in the HELLO packet, is a Hold Time
 value. This value indicates to all receivers the length of time in seconds that
 the neighbor is valid. The default Hold Time will be 3 times the HELLO interval.
 HELLO packets will be transmitted every 5 seconds (by default). There may be a
 configuration command that controls this value and therefore changes the Hold
 Time. HELLO packets are not transmitted reliably so the sequence number should
 be set to 0.

 5.3.3 UPDATE Packets
 When a router detects a new neighbor by receiving a HELLO packet from a neighbor
 not presently known, it will send a unicast UPDATE packet to the neighbor with
 no routing information. The initial UPDATE packet sent MUST have the INIT-flag
 set. This instructs the neighbor to advertise its routes. The INIT-flag is also
 useful when a neighbor goes down and comes back up before the router detects it
 went down. In this case, the neighbor needs new routing information. The INIT-
 flag informs the router to send it.

 5.3.3.1 NULL Update
 The number of destinations in its routing table will require at a minimum two
 (2) UPDATE packets to be sent. The first UPDATE packet (referred it as the NULL
 UPDATE packet) is sent with the INIT-Flag, and containing no topology
 information. The use of the NULL UPDATE is used to ensure di-directional UNICAST
 packet delivery.

 DVS: add more

 The second packet is queued, and cannot be sent until the first is acknowledged.

 5.3.4 Initialization Sequence
          Router A                           Router B
      (just booted)                     (up and running)

      (1)---------------->
          HELLO (multicast)         <----------------      (2)
          SEQ=0, ACK=0               HELLO (multicast)
                                     SEQ=0, ACK=0

                                    <----------------    (3)
                                     UPDATE (unicast)
                                     SEQ=10, ACK=0, INIT
      (4)---------------->           UPDATE 11 is queued
           UPDATE (unicast)

Savage, et al.                  Expires August 16, 2015                    [26]

Internet-Draft                          EIGRP                     August, 2015

SEQ=100, ACK=10, INIT      <----------------   (5)
                                      UPDATE (unicast)
                                      SEQ=11, ACK=100
                                      All UPDATES sent
      (6)--------------/lost/->
           ACK (unicast)
           SEQ=0, ACK=11
                                      (5 seconds later)
                                      <----------------   (7)
           Duplicate received,        UPDATE (unicast)
           Packet discarded           SEQ=11, ACK=100
      (8)--------------->
           ACK (unicast)
           SEQ=0, ACK=11

                 Figure 9 - Initialization Sequence

 (1) Router A sends multicast HELLO and Router B discovers it.

 (2) Router B sends an expedited HELLO and starts the process of sending its
 topology table to Router A. In addition, Router B sends the NULL UPDATE packet
 with the INIT-Flag. The second packet is queued, but cannot be sent until the
 first is acknowledged.

 (3) Router A receives first UPDATE packet and processes it as a DUAL event. If
 the UPDATE contains topology information, the packet will be process and stored
 in topology table. Sends its first and only UPDATE packet with an accompanied
 ACK.

 (4) Router B receives UPDATE packet 100 from Router A. Router B can dequeue
 packet 10 from A s transmission list since the UPDATE acknowledged 10. It can
 now send UPDATE packet 11 and with an acknowledgment of Router A s UPDATE.

 (5) Router A receives the last UPDATE packet from Router B and acknowledges it.
 The acknowledgment gets lost.

 (6) Router B later retransmits the UPDATE packet to Router A.

 (7) Router A detects the duplicate and simply acknowledges the packet. Router B
 dequeues packet 11 from A s transmission list and both routers are up and
 synchronized.

 5.3.5 Neighbor Formation
 To prevent packets from being sent to a neighbor prior to verifying multicast
 and unicast packet delivery is reliable, a 3-way handshake is utilized.

 During normal adjacency formation, multicast HELLOs cause the EIGRP process to
 place new neighbors into the neighbor table. Unicast packets are then used to
 exchange known routing information, and complete the neighbor relationship
 (section 5.2)

 To prevent EIGRP from sending sequenced packets to neighbor which fail to have
 bidirectional unicast/multicast, or one neighbor restarts while building the
 relationship, EIGRP MUST place the newly discovered neighbor in a  pending 
 state as follows:
 When Router-A receives the first multicast HELLO from Router-B, it places
 Router-B in the pending state, and transmits a unicast UPDATE containing no
 topology information and SHALL set the initialization bit. While Router-B is in
 this state, A will not send it any a QUERY or UPDATE. When Router-A receives the

Savage, et al.                  Expires August 16, 2015                    [27]

Internet-Draft                          EIGRP                     August, 2015

 unicast acknowledgement from Router-B, it will check the state from  pending  to
  up .

 5.3.6 QUERY Packets During Neighbor Formation
 As described above, during the initial formation of the neighbor relationship,
 EIGRP uses a form of three-way handshake to verify both unicast and multicast
 connectivity are working successfully. During this period of neighbor creation
 the new neighbor is considered to be the pending state, and is not eligible to
 be included in the convergence process. Because of this, any QUERY received by
 an EIGRP router would not cause a QUERY to be sent to the new (and pending)
 neighbor. It would perform the DUAL process without the new peer in the
 conversation.
 To do this, when a router in the process of establishing a new neighbor receives
 a QUERY from a fully established neighbor, it performs the normal DUAL Feasible
 Successor check to determine whether it needs to REPLY with a valid path or
 whether it needs to enter the ACTIVE process on the prefix.
 If it determines that it must go active, each fully established neighbor that
 participates in the convergence process will be sent a QUERY packet and REPLY
 packets are expected from each. Any pending neighbor will not be expected to
 REPLY and will not be sent a QUERY directly. If it resides on an interface
 containing a mix of fully established neighbors and pending neighbors, it might
 receive the QUERY but will not be expected to REPLY to it.

 5.4 Topology Table
 The Topology Table is populated by the protocol dependent modules (IPv4/IPv6
 PDM), and is acted upon by the DUAL finite state machine. Associated with each
 entry are the destination address and a list of neighbors that have advertised
 this destination, and the metric associated with the destination. The metric is
 referred to as the Computed Distance.

 The Computed Distance is the best-advertised Reported Distance from all
 neighbors, plus the link cost between the receiving router and the neighbor.

 The Reported Distance is the Computed Distance as advertised by the Feasible
 Successor for the destination. Said another way, the Computed distance, when
 sent by a neighbor, is referred to as the Reported Distance and is the metric
 that the neighboring router uses to reach the destination (Its Computed Distance
 as described above).

 If the router is advertising a destination route, it MUST be using the route to
 forward packets; this is an important rule that distance vector protocols MUST
 follow.

 5.4.7 Route Management
 Within the topology table, EIGRP has the notion of internal and external routes.
 Internal routes MUST be prefered over external routes independent of the metric.
 I practical terms, if and internal route is received, the Dufusion comoutation
 will be run considering only the interal routes. Only when no internal routes
 for a give destination exist, will EIGRP choose the a Successor from the
 available external routes.

 5.4.7.1 Internal Routes
 Internal routes are destinations that have been originated within the same EIGRP
 Autonomous System. Therefore, a directly attached network that is configured to
 run EIGRP is considered an internal route and is propagated with this
 information throughout the network topology.

Savage, et al.                  Expires August 16, 2015                    [28]

Internet-Draft                          EIGRP                     August, 2015

 Internal routes are tagged with the following information:
     o Router ID of the EIGRP router that originated the route.
     o Configurable administrator tag.

 5.4.7.2 External routes
 External routes are destinations that have been learned from another source,
 such as a different routing protocol or static route. These routes are marked
 individually with the identity of their origination.

 External routes are tagged with the following information:
     o Router ID of the EIGRP router that redistributed the route.
     o AS number where the destination resides.
     o Configurable administrator tag.
     o Protocol ID of the external protocol.
     o Metric from the external protocol.
     o Bit flags for default routing.

 As an example, suppose there is an AS with three border routers (BR1, BR2, and
 BR3). A border router is one that runs more than one routing protocol. The AS
 uses EIGRP as the routing protocol. Two of the border routers, BR1 and BR2, also
 use Open Shortest Path First (OSPF) and the other, BR3, also uses Routing
 Information Protocol (RIP).

 Routes learned by one of the OSPF border routers, BR1, can be conditionally
 redistributed into EIGRP. This means that EIGRP running in BR1 advertises the
 OSPF routes within its own AS. When it does so, it advertises the route and tags
 it as an OSPF learned route with a metric equal to the routing table metric of
 the OSPF route. The router-id is set to BR1. The EIGRP route propagates to the
 other border routers.

 Let's say that BR3, the RIP border router, also advertises the same destinations
 as BR1. Therefore BR3, redistributes the RIP routes into the EIGRP AS. BR2,
 then, has enough information to determine the AS entry point for the route, the
 original routing protocol used, and the metric.

 Further, the network administrator could assign tag values to specific
 destinations when redistributing the route. BR2 can use any of this information
 to use the route or re-advertise it back out into OSPF.

 Using EIGRP route tagging can give a network administrator flexible policy
 controls and help customize routing. Route tagging is particularly useful in
 transit AS s where EIGRP would typically interact with an inter-domain routing
 protocol that implements global policies.

 5.4.7.3 Split Horizon and Poison Reverse

 In some circumstances, EIGRP will suppress or poison QUERY and UPDATE
 information to prevent routing loops as changes propagate though the network.

 The split horizon rule states:
      Never advertise a route out of the interface through which it was learned. 

 EIGRP implements this to mean if you have a Successor route to a destination,
 never advertise the route out the interface on which it was learned.

Savage, et al.                  Expires August 16, 2015                    [29]

Internet-Draft                          EIGRP                     August, 2015

The poison reverse rule states:
      A route learned through an interface will be advertised as unreachable
 through that same interface. 

 Again, as with the case of Split Horizon, EIGRP implements rule as it applies to
 the interface for which the Successor route was learned.

 In EIGRP, split horizon suppresses a QUERY, where as Reverse Poison advertises a
 destination as unreachable. This can occur for a destination under any of the
 following conditions:
     o two routers are in startup or restart mode
     o advertising a topology table change
     o sending a query

 5.4.7.3.1 Startup Mode
 When two routers first become neighbors, they exchange topology tables during
 startup mode. For each destination a router receives during startup mode, it
 advertises the same destination back to its new neighbor with a maximum metric
 (Poison Route).

 5.4.7.3.2 Advertising Topology Table Change
 If a router uses a neighbor as the Successor for a given destination, it will
 send an UPDATE for the destination with a metric of infinity.

 5.4.7.3.3 Sending a QUERY/UPDATE
 In most cases EIGRP follows normal split-horizon rules. When a metric change is
 received from the Successor via QUERY or UPDATE that causes the route to go
 ACTIVE, the router will send a QUERY to neighbors on all interfaces except the
 interface toward the Successor.

 In other words, the router does not send the QUERY out of the inbound interface
 through which the information causing the route to go ACTIVE was received.

 An exception to this can occur if a router receives a QUERY from its successor
 while already reacting to an event that did not cause it to go ACTIVE. For
 example, a metric change from the Successor that did not cause an ACTIVE
 transition, but was followed by the UPDATE/QUERY that does result the router to
 transition to ACTIVE.

 5.5 EIGRP Metric Coefficients
 EIGRP allows for modification of the default composite metric calculation
 through the use of coefficients (K-values). This adjustment allows for per-
 deployment tuning of network behavior. Setting K-values up to 254 scales the
 impact of the scalar metric on the final composite metric.

 EIGRP default coefficients have been carefully selected to provide optimal
 performance in most networks. The default K-values are

             K1 == K3 == 1
             K2 == K4 == K5 == 0
             K6 == 0

 If K5 is equal to 0 then reliability quotient is defined to be 1.

Savage, et al.                  Expires August 16, 2015                    [30]

Internet-Draft                          EIGRP                     August, 2015

5.5.1 Coefficients K1 and K2
 K1 is used to allow path selection to be based on the bandwidth available along
 the path. EIGRP can use one of two variations of Throughput based path
 selection.
   o Maximum Theoretical Bandwidth; paths chosen based on the highest reported
 bandwidth
   o Network Throughput: paths chosen based on the highest  available  bandwidth
 adjusted by congestion-based effects (interface reported load)

 By default EIGRP computes the Throughput using the maximum theoretical
 throughput expressed in picoseconds per kilobyte of data sent. This inversion
 results in a larger number (more time) ultimately generating a worse metric.

 If K2 is used, the effect of congestion as a measure of load reported by the
 interface will be used to simulate the  available throughput by adjusting the
 maximum throughput.

 5.5.2 Coefficient K3
 K3 is used to allow delay or latency-based path selection. Latency and Delay
 are similar terms that refer to the amount of time it takes a bit to be
 transmitted to an adjacent neighbor. EIGRP uses one-way based values either
 provided by the interface, or computed as a factor of the links bandwidth.

 5.5.3 Coefficients K4 and K5
 K4 and K5 are used to allow for path selection based on link quality and packet
 loss. Packet loss caused by network problems result in highly noticeable
 performance issues or jitter with streaming technologies, voice over IP, online
 gaming and videoconferencing, and will affect all other network applications to
 one degree or another.

 Critical services should pass with less than 1% packet loss. Lower priority
 packet types might pass with less than 5% and then 10% for the lowest of
 priority of services. The final metric can be weighted based on the reported
 link quality.

 The handling of K5 is conditional.   If K5 is equal to 0 then reliability
 quotient is defined to be 1.

 5.5.4 Coefficient K6
 K6 has been introduced with Wide Metric support and is used to allow for
 Extended Attributes, which can be used to reflect in a higher aggregate metric
 than those having lower energy usage.
 Currently there are two Extended Attributes, jitter and energy, defined in the
 scope of this document.

 5.5.4.1 Jitter
 Use of Jitter-based Path Selection results in a path calculation with the lowest
 reported jitter. Jitter is reported as the interval between the longest and
 shortest packet delivery and is expressed in microseconds. Higher values results
 in a higher aggregate metric when compared to those having lower jitter
 calculations.

 Jitter is measured in microseconds and is accumulated along the path, with each
 hop using an averaged 3-second period to smooth out the metric change rate.

 Presently, EIGRP does not currently have the ability to measure jitter, and as
 such the default value will be zero (0). Performance based solutions such as

Savage, et al.                  Expires August 16, 2015                    [31]
Internet-Draft                          EIGRP                     August, 2015
 PfR could be used to populate this field.

 5.5.4.2 Energy
 Use of Energy-based Path Selection results in paths with the lowest energy usage
 being selected in a loop free and deterministic manner. The amount of energy
 used is accumulative and has results in a higher aggregate metric than those
 having lower energy.

 Presently, EIGRP does not report energy usage, and as such the default value
 will be zero (0).

 5.6 EIGRP Metric Calculations

 5.6.1 Classic Metrics
 One of the original goals of EIGRP was to offer and enhance routing solutions
 for IGRP. To achieve this, EIGRP used the same composite metric as IGRP, with
 the terms multiplied by 256 to change the metric from 24 bits to 32 bits.

 The composite metric is based on bandwidth, delay, load, and reliability. MTU is
 not an attribute for calculating the composite metric.

 5.6.1.1 Classic Composite Formulation
 EIGRP calculates the composite metric with the following formula:

   metric = {K1*BW+[(K2*BW)/(256 load)]+(K3*delay)}*{K5/(REL+K4)}

 In this formula, Bandwidth (BW) is the lowest interface bandwidth along the
 path, and delay is the sum of all outbound interface delays along the path. The
 router dynamically measures reliability (REL) and load. It expresses 100 percent
 reliability as 255/255. It expresses load as a fraction of 255. An interface
 with no load is represented as 1/255.

 Bandwidth is the inverse minimum bandwidth (in kbps) of the path in bits per
 second scaled by a factor of 256 multiplied by 10^7. The formula for bandwidth
 is

                   (256 x (10 ^ 7))/BWmin

 The delay is the sum of the outgoing interface delay (in microseconds) to the
 destination. A delay set to it maximum value (hexadecimal 0xFFFFFFFF) indicates
 that the network is unreachable. The formula for delay is

                   [sum of delays] x 256

 Reliability is a value between 1 and 255. Cisco IOS routers display reliability
 as a fraction of 255. That is, 255/255 is 100 percent reliability or a perfectly
 stable link; a value of 229/255 represents a 90 percent reliable link. Load is
 a value between 1 and 255. A load of 255/255 indicates a completely saturated
 link. A load of 127/255 represents a 50 percent saturated link.

 The default composite metric, adjusted for scaling factors, for EIGRP is:

           metric = 256 x { [(10^7)/ BWmin] + [sum of delays]}

 Minimum Bandwidth (BWmin) is represented in kbps, and the  sum of delays  is
 represented in 10s of microseconds. The bandwidth and delay for an Ethernet
 interface are 10Mbps and 1ms, respectively.

Savage, et al.                  Expires August 16, 2015                    [32]

Internet-Draft                          EIGRP                     August, 2015

The calculated EIGRP bandwidth (BW) metric is then:

             256 x (10^7)/BW = 256 x {(10^7)/10,000}
                             = 256 x 10,000
                             = 256,00

 And the calculated EIGRP delay metric is then:

          256 x sum of delay = 256 x 100 x 10 microseconds
                             = 25,600 (in tens of microseconds)

 5.5.1.2 Cisco Interface Delay Compatibility
 For compatibility with Cisco products, the following table shows the times in
 picoseconds EIGRP uses for bandwidth and delay
     Bandwidth        Classic     Wide Metrics     Interface
     (Kbps)           Delay       Delay            Type
     ---------------------------------------------------------
     9               500000000   500000000         Tunnel
     56               20000000    20000000         56Kb/s
     64               20000000    20000000         DS0
     1544             20000000    20000000         T1
     2048             20000000    20000000         E1
     10000             1000000     1000000         Ethernet
     16000              630000      630000         TokRing16
     45045            20000000    20000000         HSSI
     100000             100000      100000         FDDI
     100000             100000      100000         FastEthernet
     155000             100000      100000         ATM 155Mb/s
     1000000             10000       10000         GigaEthernet
     2000000             10000        5000         2 Gig
     5000000             10000        2000         5 Gig
     10000000            10000        1000         10 Gig
     20000000            10000          500        20 Gig
     50000000            10000          200        50 Gig
     100000000           10000          100        100 Gig
     200000000           10000           50        200 Gig
     500000000           10000           20        500 Gig

Savage, et al.                  Expires August 16, 2015                    [33]

Internet-Draft                          EIGRP                     August, 2015

 5.6.2 Wide Metrics
 To accommodate interfaces with high bandwidths, and to allow EIGRP to perform
 the path selection; the EIGRP packet and composite metric formula has been
 modified to choose paths based on the computed time, measured in picoseconds,
 information takes to travel though the links.

 5.6.2.1 Wide Metric Vectors
 EIGRP uses five  vector  metrics: minimum throughput, latency, load,
 reliability, and maximum transmission unit (MTU). These values are calculated
 from destination to source as follows:
          o Throughput - Minimum value
          o Latency       - accumulative
          o Load          - maximum
          o Reliability   - minimum
          o MTU           - minimum
          o Hop count     - accumulative

 To this there are two additional values: jitter and energy. These two values are
 accumulated from destination to source:
         o Jitter - accumulative
         o Energy - accumulative

 These Extended Attributes, as   well as any future ones, will be controlled via
 K6. If K6 is non-zero, these    will be additive to the path s composite metric.
 Higher jitter or energy usage   will result in paths that are worse than those
 which either does not monitor   these attributes, or which have lower values.

 EIGRP will not send these attributes if the router does not provide them. If
 the attributes are received, then EIGRP will use them in the metric calculation
 (based on K6) and will forward them with those routers values assumed to be
  zero  and the accumulative values are forwarded unchanged.

 The use of the vector metrics allows EIGRP to compute paths based on any of four
 (bandwidth, delay, reliability, and load) path selection schemes. The schemes
 are distinguished based on the choice of the key measured network performance
 metric.

 Of these vector metric components, by default, only minimum throughput and
 latency are traditionally used to compute best path. Unlike most metrics,
 minimum throughput is set to the minimum value of the entire path, and it does
 not reflect how many hops or low throughput links are in the path, nor does it
 reflect the availability of parallel links. Latency is calculated based on one-
 way delays, and is a cumulative value, which increases with each segment in the
 path.

 Network Designers Note: when trying to manually influence EIGRP path selection
 though interface bandwidth/delay configuration, the modification of bandwidth is
 discouraged for following reasons:

 The change will only effect the path selection if the configured value is the
 lowest bandwidth over the entire path.
 Changing the bandwidth can have impact beyond affecting the EIGRP metrics. For
 example, Quality of Service (QoS) also looks at the bandwidth on an interface.

 EIGRP throttles its packet transmissions so it will only use 50 percent of the
 configured bandwidth. Lowering the bandwidth can cause EIGRP to starve an
 adjacency, causing slow or failed convergence and control plane operation.

Savage, et al.                  Expires August 16, 2015                    [34]

Internet-Draft                          EIGRP                     August, 2015

 Changing the delay does not impact other protocols nor does it cause EIGRP to
 throttle back; changing the delay configured on a link only impacts metric
 calculation.

 5.6.2.2 Wide Metric Conversion Constants
 EIGRP uses a number of defined constants for conversion and calculation of
 metric values. These numbers are provided here for reference

         EIGRP_BANDWIDTH                   10,000,000
         EIGRP_DELAY_PICO                   1,000,000
         EIGRP_INACCESSIBLE      0xFFFFFFFFFFFFFFFFLL
         EIGRP_MAX_HOPS                           100
         EIGRP_CLASSIC_SCALE                      256
         EIGRP_WIDE_SCALE                       65536

 When computing the metric using the above units, all capacity information will
 be normalized to kilobytes and picoseconds before being used. For example,
 delay is expressed in microseconds per kilobyte, and would be converted to
 kilobytes per second; likewise energy would be expressed in power per kilobytes
 per second of usage.

 5.6.2.3 Throughput Calculation
 The formula for the conversion for Max-Throughput value directly from the
 interface without consideration of congestion-based effects is as follows:

                               (EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE)
      Max-Throughput = K1 *    ------------------------------------
                                    Interface Bandwidth (kbps)

 If K2 is used, the effect of congestion as a measure of load reported by the
 interface will be used to simulate the  available throughput by adjusting the
 maximum throughput according to the formula:

                                         K2 * Max-Throughput
      Net-Throughput = Max-Throughput + ---------------------
                                            256   Load
 K2 has the greatest effect on the metric occurs when the load increases beyond
 90%.

 5.6.2.4 Latency Calculation
 Transmission times derived from physical interfaces MUST be n units of
 picoseconds, or converted to picoseconds prior to being exchanged between
 neighbors, or used in the composite metric determination.

 This includes delay values present in configuration-based commands (i.e.
 interface delay, redistribute, default-metric, route-map, etc.)

 The delay value is then converted to a  latency  using the formula:

                        Delay * EIGRP_WIDE_SCALE
      Latency = K3 *   --------------------------
                           EIGRP_DELAY_PICO

Savage, et al.                  Expires August 16, 2015                    [35]

Internet-Draft                          EIGRP                     August, 2015

 5.6.2.5 Composite Calculation
                                                              K5
    metric =[(K1*Net-Throughput) + Latency)+(K6*ExtAttr)] * ------
                                                            K4+Rel

 By default, the path selection scheme used by EIGRP is a combination of
 Throughput and Latency where the selection is a product of total latency and
 minimum throughput of all links along the path:

    metric = (K1 * min(Throughput)) + (K3 * sum(Latency)) }

 6 Security Considerations
 By the nature of being promiscuous, EIGRP will neighbor with any router that
 sends a valid HELLO packet. Due to security considerations, this  completely 
 open aspect requires policy capabilities to limit peering to valid routers.

 EIGRP does not rely on a PKI or a more heavy weight authentication system. These
 systems challenge the scalability of EIGRP, which was a primary design goal.

 Instead, Denial of Service (DoS) attack prevention will depend on
 implementations rate-limiting packets to the control plane as well as
 authentication of the neighbor though the use of MD5 or SHA2-256

Savage, et al.                  Expires August 16, 2015                    [36]

Internet-Draft                          EIGRP                     August, 2015

7 IANA Considerations
 This draft references the two multicast addresses:

       224.0.0.10           IGRP Routers                 [multicast-addresses]
       FF02:0:0:0:0:0:0:A   EIGRP Routers           [ipv6-multicast-addresses]

 Please see
     http://www.iana.org/assignments/multicast-addresses
     http://www.iana.org/assignments/ipv6-multicast-addresses

 8 References

 8.1 Normative References
 [1]        Bradner, S., "Key words for use in RFCs to Indicate Requirement
 Levels", BCP 14, [RFC2119], April 1997.

 [2]        Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
 Specifications: ABNF", [RFC5234], Internet Mail Consortium and Demon Internet
 Ltd., November 1997.

 [3]        A Unified Approach to Loop-Free Routing using Distance Vectors or
 Link States, J.J. Garcia-Luna-Aceves, 1989 ACM 089791-332-9/89/0009/0212, pages
 212-223.

 [4]        Loop-Free Routing using Diffusing Computations, J.J. Garcia-Luna-
 Aceves, Network Information Systems Center, SRI International to appear in
 IEEE/ACM Transactions on Networking, Vol. 1, No. 1, 1993.

 [5]         BGP Extended Communities Attribute [RFC4360]

 [6]         Assigning Experimental and Testing Numbers Considered Useful
 [RFC3692]

 [7]         HMAC-SHA256, SHA384, SHA512 in IPsec [RFC4868]

 8.2 Informative References
 [8]         OSPF Version 2, Network Working Group [RFC2328], J. Moy, April 1998.

 [9]         Guidelines for Considering New Performance Metric Development
 [RFC6390]

 [10]       Address Family Numbers, http://www.iana.org/assignments/address-
 family-numbers/address-family-numbers.xhtml#address-family-numbers-2

Savage, et al.                  Expires August 16, 2015                    [37]

Internet-Draft                          EIGRP                     August, 2015

 9 Acknowledgments
 This document was prepared using 2-Word-v2.0.template.dot.

 An initial thank you goes to Dino Farinacci, Bob Albrightson, and Dave Katz.
 Their significant accomplishments towards the design and development of the
 EIGRP protocol provided the bases for this document.

 A special and appreciative thank you goes to the core group of Cisco engineers
 whose dedication, long hours, and hard work lead the evolution of EIGRP over the
 following decade. They are Donnie Savage, Mickel Ravizza, Heidi Ou, Dawn Li,
 Thuan Tran, Catherine Tran, Don Slice, Claude Cartee, Donald Sharp, Steven
 Moore, Richard Wellum, Ray Romney, Jim Mollmann, Dennis Wind, Chris Van Heuveln,
 Gerald Redwine, Glen Matthews, Michael Wiebe, and others.

 The authors would like to gratefully acknowledge many people who have
 contributed to the discussions that lead to the making of this proposal. They
 include Chris Le, Saul Adler, Scott Van de Houten, Lalit Kumar, Yi Yang, Kumar
 Reddy, David Lapier, Scott Kirby, David Prall, Jason Frazier, Eric Voit, Dana
 Blair, Jim Guichard, and Alvaro Retana.

 In addition to the tireless work provided by the Cisco engineers over the years,
 I would like to personally call out the team what crated the first Open Source
 verison of EIGRP. This team comprises of: Jan Janovic, Matej Perina, Peter
 Orsag, and Peter Paluch who made it all possible.

Savage, et al.                  Expires August 16, 2015                    [38]

Internet-Draft                          EIGRP                     August, 2015

 10 EIGRP Packet Formats

 10.1 Protocol Number
 The IPv6 and IPv4 protocol identifier number spaces are common and will both use
 protocol identifier 88.

 EIGRP IPv6 will transmit HELLO packets with a source address being the link-
 local address of the transmitting interface. Multicast HELLO packets will have a
 destination address of FF02::A (the EIGRP IPv6 multicast address). Unicast
 packets directed to a specific neighbor will contain the destination link-local
 address of the neighbor.

 There is no requirement that two EIGRP IPv6 neighbors share a common prefix on
 their connecting interface. EIGRP IPv6 will check that a received HELLO contains
 a valid IPv6 link-local source address. Other HELLO processing will follow
 common EIGRP checks, including matching Autonomous system number and matching K-
 values.

 10.2 Protocol Assignment Encoding
 External Protocol Field is an informational assignment to identify the
 originating routing protocol that this route was learned by. The following
 values are assigned:

         Protocols             Value
         IGRP                    1
         EIGRP                   2
         Static                  3
         RIP                     4
         HELLO                   5
         OSPF                    6
         ISIS                    7
         EGP                     8
         BGP                     9
         IDRP                   10
         Connected              11

 10.3 Destination Assignment Encoding
 Destinations types are encoded according to the IANA address family number
 assignments. Currently on the following types are used:

       AFI Designation            AFI Value
      --------------------------------------
       IPv4 Address                   1
       IPv6 Address                   2
       Service Family Common      16384
       Service Family IPv4        16385
       Service Family IPv6        16386

Savage, et al.                  Expires August 16, 2015                    [39]

Internet-Draft                          EIGRP                     August, 2015

10.4 EIGRP Communities Attribute
 EIGRP supports communities similar to the BGP Extended Communities [5] extended
 type with Type Field composed of 2 octets and Value Field composed of 6 octets.
 Each Community is encoded as an 8-octet quantity, as follows:
        - Type Field: 2 octets
        - Value Field: Remaining octets

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type high     | Type low      |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 In addition to well-known communities supported by BGP (such as Site of Origin),
 EIGRP defines a number of additional Community values in the  Experimental Use
 [6]  range as follows:

   Type high: 0x88
   Type low:

     Value       Name               Description
     ---------------------------------------------------------------
       00        EXTCOMM_EIGRP      EIGRP route information appended
       01        EXTCOMM_DAD        Data: AS + Delay
       02        EXTCOMM_VRHB       Vector: Reliability + Hop + BW
       03        EXTCOMM_SRLM       System: Reserve +Load + MTU
       04        EXTCOMM_SAR        System: Remote AS + Remote ID
       05        EXTCOMM_RPM        Remote: Protocol + Metric
       06        EXTCOMM_VRR        Vecmet: Rsvd + RouterID

 10.5 EIGRP Packet Header
 The basic EIGRP packet payload format is identical for all three protocols,
 although there are some protocol-specific variations. Packets consist of a
 header, followed by a set of variable-length fields consisting of
 Type/Length/Value (TLV) triplets.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Header Version | Opcode        |           Checksum            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Flags                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Sequence Number                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Acknowledgement number                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Virtual Router ID               | Autonomous system number    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Header Version - EIGRP Packet Header Format version.   Current Version is 2.
 This field is not the same as the TLV Version field.

Savage, et al.                  Expires August 16, 2015                    [40]

Internet-Draft                          EIGRP                     August, 2015

Opcode - EIGRP opcode indicating function packet serves.    It will be one of the
 following values:

         EIGRP_OPC_UPDATE             1
         EIGRP_OPC_REQUEST            2
         EIGRP_OPC_QUERY              4
         EIGRP_OPC_REPLY              4
         EIGRP_OPC_HELLO              5
         Reserved                     6
         Reserved                     7
         Reserved                     8
         Reserved                     9
         EIGRP_OPC_SIAQUERY          10
         EIGRP_OPC_SIAREPLY          11

 Checksum - Each packet will include a checksum for the entire contents of the
 packet. The check-sum will be the standard ones complement of the ones
 complement sum. The packet is discarded if the packet checksum fails.

 Flags - Defines special handling of the packet. There are currently two defined
 flag bits.

 Init Flag (0x01) - This bit is set in the initial UPDATE sent to a newly
 discovered neighbor. It requests the neighbor to download a full set of routes.

 CR Flag (0x02) - This bit indicates that receivers should only accept the packet
 if they are in Conditionally Received mode. A router enters conditionally
 received mode when it receives and processes a HELLO packet with a Sequence TLV
 present.

 RS (0x04) -   The Restart flag is set in the HELLO and the UPDATE packets during
 the restart   period. The router looks at the RS flag to detect if a neighbor is
 restarting,   From the restarting routers perspective, if a neighboring router
 detects the   RS flag set, it will maintains the adjacency, and will set the RS
 flag in its   UPDATE packet to indicated it is doing a soft restart.

 EOT (0x08) - The End-of-Table flag marks the end of the startup process with a
 neighbor. If the flag is set, it indicates the neighbor has completed sending
 all UPDATEs. At this point the router will remove any stale routes learned from
 the neighbor prior to the restart event. A state route is any route, which
 existed before the restart, and was not refreshed by the neighbor via and
 UPDATE.

 Sequence - Each packet that is transmitted will have a 32-bit sequence number
 that is unique respect to a sending router. A value of 0 means that an
 acknowledgment is not required.

 ACK   The 32-bit sequence number that is being acknowledged with respect to
 receiver of the packet. If the value is 0, there is no acknowledgment present. A
 non-zero value can only be present in unicast-addressed packets. A HELLO packet
 with a nonzero ACK field should be decoded as an ACK packet rather than a HELLO
 packet.

Savage, et al.                  Expires August 16, 2015                    [41]

Internet-Draft                          EIGRP                     August, 2015

 Virtual Router ID (VRID)   A 16-bit number, which identifies the virtual router,
 this packet is associated. Packets received with an unknown, or unsupported VRID
 will be discarded.

        Value Range      Usage
          0000           Unicast Address Family
          0001           Multicast Address Family
          0002-7FFFF     Reserved
          8000           Unicast Service Family
          8001-FFFF      Reserved

 Autonomous System (AS)   16 bit unsigned number of the sending system. This
 field is indirectly used as an authentication value. That is, a router that
 receives and accepts a packet from a neighbor must have the same AS number or
 the packet is ignored.

 10.6 EIGRP TLV Encoding Format
 The contents of each packet can contain a variable number of fields. Each field
 will be tagged and include a length field. This allows for newer versions of
 software to add capabilities and coexist with old versions of software in the
 same configuration. Fields that are tagged and not recognized can be skipped
 over. Another advantage of this encoding scheme allows multiple network layer
 protocols to carry independent information. Therefore, later if it is decided to
 implement a single  integrated  protocol this can be done.

 The format of a {type, length, value} (TLV) is encoded as follows:

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type high     | Type low      |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Value (variable length)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The type values are the ones defined below. The length value specifies the
 length in octets of the type, length and value fields. TLVs can appear in a
 packet in any order and there are no inter-dependencies among them.

 10.6.1 Type Field Encoding
 The type field is structured as follows:
 Type High: 1 octet that defines the protocol classification:
          Protocol            ID   VERSION
          General            0x00    1.2
          IPv4               0x01    1.2
          IPv6               0x04    1.2
          SAF                0x05    3.0
          Multi-Protocol     0x06    2.0

 Type Low: 1 octet that defines the TLV Opcode
 See TLV Definitions in Section 3

 10.6.2 Length Field Encoding
 The Length field is a 2 octet unsigned number, which indicates the length of the
 TLV. The value does includes the Type and Length fields

Savage, et al.                  Expires August 16, 2015                    [42]

Internet-Draft                          EIGRP                     August, 2015

10.6.3 Value Field Encoding
 The Value field is a multi-octet field containing the payload for the TLV.

 10.7 EIGRP Generic TLV Definitions
                                      Ver 1.2   Ver 2.0
       PARAMETER_TYPE                 0x0001    0x0001
       AUTHENTICATION_TYPE            0x0002    0x0002
       SEQUENCE_TYPE                  0x0003    0x0003
       SOFTWARE_VERSION_TYPE          0x0004    0x0004
       MULTICAST_SEQUENCE _TYPE       0x0005    0x0005
       PEER_INFORMATION _TYPE         0x0006    0x0006
       PEER_TERMINATION_TYPE          0x0007    0x0007
       PEER_TID_LIST_TYPE              ---      0x0008

 10.7.1 0x0001 - PARAMETER_TYPE
 This TLV is used in HELLO packets to convey the EIGRP metric coefficient values
   noted as  K-values  as well as the Hold Time values. This TLV is also used in
 an initial UPDATE packet when a neighbor is discovered.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            0x0001             |            0x000C             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       K1      |       K2      |       K3      |       K4      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       K5      |       K6      |           Hold Time           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 K-values - The K-values associated with the EIGRP composite metric equation.
 The default values for weights are:
           K1 - 1
           K2 - 0
           K3 - 1
           K4 - 0
           K5 - 0
           K6   0

 Hold Time - The amount of time in seconds that a receiving router should
 consider the sending neighbor valid. A valid neighbor is one that is able to
 forward packets and participates in EIGRP. A router that considers a neighbor
 valid will store all routing information advertised by the neighbor.

 10.7.2 0x0002 - AUTHENTICATION_TYPE
 This TLV may be used in any EIGRP packet and conveys the authentication type and
 data used. Routers receiving a mismatch in authentication shall discard the
 packet.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             0x0002            |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Auth Type    | Auth Length  |      Auth Data (Variable)     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Authentication Type - The type of authentication used.

Savage, et al.                  Expires August 16, 2015                    [43]

Internet-Draft                          EIGRP                     August, 2015

Authentication Length - The length, measured in octets, of the individual
 authentication.

 Authentication Data - Variable length field reflected by  Auth Length  which is
 dependent on the type of authentication used. Multiple authentication types can
 be present in a single AUTHENTICATION_TYPE TLV.

 10.7.2.1 0x02 - MD5 Authentication Type
 MD5 Authentication will use Auth Type code 0x02, and the Auth Data will be the
 MD5 Hash value.

 10.7.2.2 0x03 - SHA2 Authentication Type
 SHA2-256 Authentication will use Type code 0x03, and the Auth Data will be the
 256 bit SHA2 [6] Hash value

 10.7.3 0x0003 - SEQUENCE_TYPE
 This TLV is used for a sender to tell receivers to not accept packets with the
 CR-flag set. This is used to order multicast and unicast addressed packets.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            0x0003             |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Address Length |                 Protocol Address              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The Address Length and Protocol Address will be repeated one or more times based
 on the Length Field.

 Address Length - Number of octets for the address that follows. For IPv4, the
 value is 4. For AppleTalk, the value is 4. For Novell IPX, the value is 10, for
 IPv6 it is 16

 Protocol Address - Neighbor address on interface in which the HELLO with
 SEQUENCE TLV is sent. Each address listed in the HELLO packet is a neighbor that
 should not enter Conditionally Received mode.

 10.7.4 0x0004 - SOFTWARE_VERSION_TYPE
         Field                        Length
         Vender OS major version        1
         Vender OS minor version        1
         EIGRP major revision           1
         EIGRP minor revision           1

 The EIGRP TLV Version fields are used to determine TLV format versions. Routers
 using Version 1.2 TLVs do not understand version 2.0 TLVs, therefore Version 2.0
 routers must send the packet with both TLV formats in a mixed network.

 10.7.5 0x0005 - MULTICAST_SEQUENCE_TYPE
 The next multicast sequence TLV

 10.7.6 0x0006 - PEER_INFORMATION_TYPE
 This TLV is reserved, and not part of this IETF draft.

Savage, et al.                  Expires August 16, 2015                    [44]

Internet-Draft                          EIGRP                     August, 2015

10.7.7 0x0007 - PEER_TERMAINATION_TYPE
 This TLV is used in HELLO Packets to specify a given neighbor has been reset.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            0x0007              |             Length           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Address List (variable)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 10.7.8 0x0008 - TID_LIST_TYPE
 List of sub-topology identifiers, including the base topology, supported but the
 router.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            0x0008             |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Topology Identification List (variable)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 If this information changes from the last state, it means either a new topology
 was added, or an existing topology was removed. This TLV is ignored until
 three-way handshake has finished

 When the TID list received, it compares the list to the previous list sent. If
 a TID is found which does not previously exist, the TID is added to the
 neighbor s topology list, and the existing sub-topology is sent to the peer.

 If a TID, which was in a previous list, is not found, the TID is removed from
 the neighbor s topology list and all routes learned though that neighbor for
 that sub-topology is removed from the topology table.

 10.8 Classic Route Information TLV Types

 10.8.1 Classic Flag Field Encoding
 EIGRP transports a number of flags with in the TLVs to indicate addition route
 state information. These bits are defined as follows:

 Flags Field
 -----------
 Source Withdraw (Bit 0) - Indicates if the router which is the original source
 of the destination is withdrawing the route from the network, or if the
 destination is lost due as a result of a network failure.

 Candidate Default (CD) (Bit 1)   Set to indicate the destination should be
 regarded as a candidate for the default route. An EIGRP default route is
 selected from all the advertised candidate default routes with the smallest
 metric.

 ACTIVE (Bit 2) - Indicates if the route is in the ACTIVE State.

Savage, et al.                  Expires August 16, 2015                    [45]

Internet-Draft                          EIGRP                     August, 2015

10.8.2 Classic Metric Encoding
 The handling of bandwidth and delay for Classic TLVs are encoded in the packet
  scaled  form relative to how they are represented on the physical link.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Scaled Delay                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Scaled Bandwidth                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   MTU                         | Hop-Count     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Reliability   |       Load     | Internal Tag | Flags Field |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Scaled Delay - An administrative parameter assigned statically on a per
 interface type basis to represent the time it takes a along an unloaded path.
 This is expressed in units of 10s of microseconds divvied by 256. A delay of
 0xFFFFFFFF indicates an unreachable route.

 Scaled Bandwidth - The path bandwidth measured in bits per second. In units of
 2,560,000,000/kbps
 MTU - The minimum maximum transmission unit size for the path to the
 destination.

 Hop Count - The number of router traversals to the destination.

 Reliability - The current error rate for the path. Measured as an error
 percentage. A value of 255 indicates 100% reliability

 Load - The load utilization of the path to the destination, measured as a
 percentage. A value of 255 indicates 100% load.

 Internal-Tag - A tag assigned by the network administrator that is untouched by
 EIGRP. This allows a network administrator to filter routes in other EIGRP
 border routers based on this value.

 Flag Field - See Section 10.8.1

 10.8.3 Classic Exterior Encoding
 Additional routing information so provided for destinations outside of the EIGRP
 autonomous system as follows:

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Router Identification (RID)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                  Autonomous System Number (AS)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    External Protocol Metric                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Reserved             |Extern Protocol| Flags Field |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Router Identifier (RID)   A 32bit number provided by the router sourcing the
 information to uniquely identify it as the source.

Savage, et al.                  Expires August 16, 2015                    [46]

Internet-Draft                          EIGRP                     August, 2015

 Autonomous System (AS)   32-bit number indicating the external autonomous system
 the sending router is a member of. If the source protocol is EIGRP, this field
 will be the [VRID|AS] pair.

 External Protocol Metric   32bit value of the composite metric that resides in
 the routing table as learned by the foreign protocol. If the External Protocol
 is IGRP or another EIGRP routing process, the value can optionally be the
 composite metric or 0, and the metric information is stored in the metric
 section.

 External Protocol - Defines the external protocol that this route was learned.
 See Section 10.2

 Flag Field - See Section 10.8.1

 10.8.4 Classic Destination Encoding
 EIGRP carries destination in a compressed form, where the number of bits
 significant in the variable length address field are indicated in a counter

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Subnet Mask   |    Destination Address (variable length       |
 | Bit Count     |         ((Bit Count - 1) / 8) + 1             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Subnet Mask Bit Count   8-bit value used to indicate the number of bits in the
 subnet mask. A value of 0 indicates the default network and no address is
 present.

 Destination Address   A variable length field used o carry the destination
 address. The length is determined by the number of consecutive bits in the
 destination address, rounded up to the nearest octet boundary, determines the
 length of the address.

Savage, et al.                  Expires August 16, 2015                    [47]

Internet-Draft                          EIGRP                     August, 2015

 10.8.5 IPv4 Specific TLVs
            INTERNAL_TYPE    0x0102
            EXTERNAL_TYPE    0x0103
            COMMUNITY_TYPE   0x0104

 10.8.5.1 IPv4 INTERNAL_TYPE
 This TLV conveys IPv4 destination and associated metric information for IPv4
 networks. Routes advertised in this TLV are network interfaces that EIGRP is
 configured on as well as networks that are learned via other routers running
 EIGRP.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      0x01     |       0x02     |            Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Next Hop Forwarding Address                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Vector Metric Section (See Section 10.8.2)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |                       Destination Section                     |
 |                 IPv4 Address (variable length)                |
 |                       (See Section 10.8.4)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Next Hop Forwarding Address - IPv4 address is represented by 4 8-bit values
 (total 4 octets). If the value is zero (0), the IPv6 address from the received
 IPv4 header is used as the next-hop for the route. Otherwise, the specified IPv4
 address will be used.

 Metric Section   vector metrics for destinations contained in this TLV. See
 description of metric encoding in section 10.8.2

 Destination Section - The network/subnet/host destination address being
 requested. See description of destination in section10.8.4

 10.8.5.2 IPv4 EXTERNAL_TYPE
 This TLV conveys IPv4 destination and metric information for routes learned by
 other routing protocols that EIGRP injects into the AS. Available with this
 information is the identity of the routing protocol that created the route, the
 external metric, the AS number, an indicator if it should be marked as part of
 the EIGRP AS, and a network administrator tag used for route filtering at EIGRP
 AS boundaries.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      0x01     |       0x03     |            Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Next Hop Forwarding Address                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 Exterior Section (See Section10.8.3)          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Vector Metric Section (See Section 10.8.2)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |                       Destination Section                     |
 |                 IPv4 Address (variable length)                |
 |                       (See Section 10.8.4)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Savage, et al.                  Expires August 16, 2015                    [48]

Internet-Draft                          EIGRP                     August, 2015

 Next Hop Forwarding Address - IPv4 address is represented by 4 8-bit values
 (total 4 octets). If the value is zero (0), the IPv6 address from the received
 IPv4 header is used as the next-hop for the route. Otherwise, the specified IPv4
 address will be used

 Exterior Section   Additional routing information provide for a destination
 outside of the autonomous system and that has been redistributed into the EIGRP.
 See Section 10.8.3

 Metric Section   vector metrics for destinations contained in this TLV. See
 description of metric encoding in section 10.8.2

 Destination Section - The network/subnet/host destination address being
 requested. See description of destination in Section 10.8.4

 10.8.5.3 IPv4 COMMUNITY_TYPE
 This TLV is used to provide community tags for specific IPv4 destinations.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      0x01     |       0x04     |             Length           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          IPv4 Destination                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Reserved            |       Community Length       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Community List                        |
 |                        (variable length)                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Destination   - The IPv4 address the community information should be stored with.

 Community Length - 2 octet unsigned number that indicates the length of the
 Community List. The length does not includes the IPv4 Address, reserved, or
 Length fields

 Community List   One or more 8 octet EIGRP community as defined in section 10.4

Savage, et al.                  Expires August 16, 2015                    [49]

Internet-Draft                          EIGRP                     August, 2015

 10.8.6 IPv6 Specific TLVs
          REQUEST_TYPE                0x0401
          INTERNAL_TYPE               0x0402
          EXTERNAL_TYPE               0x0403

 10.8.6.1 IPv6 INTERNAL_TYPE
 This TLV conveys IPv6 destination and associated metric information for IPv6
 networks. Routes advertised in this TLV are network interfaces that EIGRP is
 configured on as well as networks that are learned via other routers running
 EIGRP.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      0x04     |       0x02     |            Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Next Hop Forwarding Address                 |
 |                            (16 octets)                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Vector Metric Section (See Section 10.8.2)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |                       Destination Section                     |
 |                 IPv4 Address (variable length)                |
 |                       (See Section 10.8.4)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Next Hop Forwarding Address - IPv6 address is represented by 8 groups of 16-bit
 values (total 16 octets). If the value is zero (0), the IPv6 address from the
 received IPv6 header is used as the next-hop for the route.

 Metric Section   vector metrics for destinations contained in this TLV. See
 description of metric encoding in section 10.8.2

 Destination Section - The network/subnet/host destination address being
 requested. See description of destination in section 10.8.4

 10.8.6.2 IPv6 EXTERNAL_TYPE
 This TLV conveys IPv6 destination and metric information for routes learned by
 other routing protocols that EIGRP injects into the. Available with this
 information is the identity of the routing protocol that created the route, the
 external metric, the AS number, an indicator if it should be marked as part of
 the EIGRP AS, and a network administrator tag used for route filtering at EIGRP
 AS boundaries.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      0x04     |        0x03     |           Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Next Hop Forwarding Address                 |
 |                             (16 octets)                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Exterior Section (See Section 10.8.3)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Vector Metric Section (See Section 10.8.2)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |                        Destination Section                    |
 |                 IPv4 Address (variable length)                |
 |                       (See Section 10.8.4)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Savage, et al.                  Expires August 16, 2015                    [50]

Internet-Draft                          EIGRP                     August, 2015

 Next Hop Forwarding Address - IPv6 address is represented by 8 groups of 16-bit
 values (total 16 octets). If the value is zero (0), the IPv6 address from the
 received IPv6 header is used as the next-hop for the route. Otherwise, the
 specified IPv6 address will be used.

 Exterior Section   Additional routing information provide for a destination
 outside of the autonomous system and that has been redistributed into the EIGRP.
 See Section 10.8.3

 Metric Section   vector metrics for destinations contained in this TLV. See
 description of metric encoding in section 10.8.2

 Destination Section - The network/subnet/host destination address being
 requested. See description of destination in section 10.8.4

 10.8.6.3 IPv6 COMMUNITY_TYPE
 This TLV is used to provide community tags for specific IPv4 destinations.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      0x01     |       0x04     |             Length           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            Destination                        |
 |                            (16 octets)                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Reserved            |       Community Length       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Community List                        |
 |                        (variable length)                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Destination   - The IPv6 address the community information should be stored with.

 Community Length - 2 octet unsigned number that indicates the length of the
 Community List. The length does not includes the IPv4 Address, Reserved or
 Length fields

 Community List   One or more 8 octet EIGRP community as defined in section 10.4

Savage, et al.                  Expires August 16, 2015                    [51]

Internet-Draft                          EIGRP                     August, 2015

 10.9 Multi-Protocol Route Information TLV Types
 This TLV conveys topology and associated metric information

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Header Version |    Opcode      |           Checksum           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                              Flags                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Sequence Number                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Acknowledgement number                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Virtual Router ID                | Autonomous system number   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            TLV Header Encoding                |
 |                           (See Section 10.9.1)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Wide Metric Encoding                |
 |                           (See Section 10.9.2)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Destination Descriptor                |
 |                             (variable length)                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 10.9.1 TLV Header Encoding
 There has been a long-standing requirement for EIGRP to support routing
 technologies such as multi-topologies and provide the ability to carry
 destination information independent of the transport. To accomplish this, a
 Vector has been extended to have a new  Header Extension Header  section. This
 is a variable length field and, at a minimum, will support the following fields:

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type high     | Type low      |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               AFI             |             TID               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Router Identifier (RID)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Value (variable length)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The available fields are:
 TYPE - Topology TLVs have the following TYPE codes:

     Type High: 0x06
     Type Low:
         REQUEST_TYPE                 0x01
         INTERNAL_TYPE                0x02
         EXTERNAL_TYPE                0x03

 Router Identifier (RID)   A 32bit number provided by the router sourcing the
 information to uniquely identify it as the source.

Savage, et al.                  Expires August 16, 2015                    [52]

Internet-Draft                          EIGRP                     August, 2015

10.9.2 Wide Metric Encoding
 Multi-Protocol TLV s will provide an extendable section of metric information,
 which is not used for the primary routing compilation. Additional per path
 information is included to enable per-path cost calculations in the future. Use
 of the per-path costing along with the VID/TID will prove a complete solution
 for multidimensional routing.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Offset     |   Priority     | Reliability |        Load      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               MTU                               |   Hop-Count   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               Delay                             |
 |                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                |                                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 |
 |                             Bandwidth                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Reserved         |         Opaque Flags           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Extended Attributes                        |
 |                        (variable length)                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The fields are:
 Offset   Number of 16bit words in the Extended Attribute section, used to
 determine the start of the destination information. If no Extended Attributes
 are attached, offset will be zero.

 Priority - Priority of the prefix when processing route. In an AS using priority
 values, a destination with a higher priority receives preferential treatment and
 is serviced before a destination with a lower priority. A priority of zero
 indicates no priority is set.

 Reliability - The current error rate for the path. Measured as an error
 percentage. A value of 255 indicates 100% reliability

 Load - The load utilization of the path to the destination, measured as a
 percentage. A value of 255 indicates 100% load.

 MTU - The minimum maximum transmission unit size for the path to the
 destination. Not used in metric calculation, but available to underlying
 protocols

 Hop Count - The number of router traversals to the destination.

 Delay   The one-way latency along an unloaded path to the destination expressed
 in units of picoseconds per kilobit. This number is not scaled, a value of
 0xFFFFFFFFFFFF indicates an unreachable route.

 Bandwidth - The path bandwidth measured in kilobit per second as presented by
 the interface. This number is not scaled, as is the case with  scaled
 bandwidth . A bandwidth of 0xFFFFFFFFFFFF indicates an unreachable route.

 Reserved   Transmitted as 0x0000

 Opaque Flags   16 bit protocol specific flags.

Savage, et al.                  Expires August 16, 2015                    [53]

Internet-Draft                          EIGRP                     August, 2015

Extended Attributes   (Optional) When present, defines extendable per
 destination attributes. This field is not normally transmitted.

 10.9.3 Extended Metrics
 Extended metrics allows for extensibility of the vector metrics in a manor
 similar to RFC-6390 [9]. Each Extended metric shall consist of a standard Type-
 Length header followed by application-specific information. Extended metrics
 values not understood must be treated as opaque and passed along with the
 associated route.

 The general formats for the Extended Metric fields are:
   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Opcode    |      Offset   |              Data             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Opcode   Indicates the type of Extended Metric

 Offset   Number of 16bit words in the sub-field. Offset does not include the
 length of the opcode or offset fields)

 Data   Zero or more octets of data as defined by Opcode

 10.9.3.1 0x00   NoOp
 This is used to pad the attribute section to ensure 32-bit alignment of the
 metric encoding section.

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     0x00      |      0x00     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The fields are:
 Opcode   Transmitted as zero (0)

 Offset   Transmitted as zero (0) indicating no data is present

 Data   No data is present with this attribute.

 10.9.3.2 0x01   Scaled Metric
 If a route is received from a back-rev neighbor, and the route is selected as
 the best path, the scaled metric received in the older UPDATE, may be attached
 to the packet. If received, the value is for informational purposes, and is not
 affected by K6

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       0x01    |       0x04    |          Reserved             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Scaled Bandwidth                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Scaled Delay                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Savage, et al.                  Expires August 16, 2015                    [54]

Internet-Draft                          EIGRP                     August, 2015

 Reserved   Transmitted as 0x0000

 Scaled Delay - An administrative parameter assigned statically on a per
 interface type basis to represent the time it takes a along an unloaded path.
 This is expressed in units of 10s of microseconds divvied by 256. A delay of
 0xFFFFFFFF indicates an unreachable route.

 Scaled Bandwidth - The minimum bandwidth along a path expressed in units of
 2,560,000,000/kbps. A bandwidth of 0xFFFFFFFF indicates an unreachable route.

 10.9.3.3 0x02   Administrator Tag
 This is used to provide and administrative tags for specific topology entries.
 It is not affected by K6

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       0x02    |       0x02    |       Administrator Tag       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Administrator Tag (cont)      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Administrator Tag - A tag assigned by the network administrator that is
 untouched by EIGRP. This allows a network administrator to filter routes in
 other EIGRP border routers based on this value.

 10.9.3.4 0x03   Community List
 This is used to provide communities for specific topology entries. It is not
 affected by K6

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       0x03    |      Offset    |          Community List      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
 |                          (variable length)                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Offset   Number of 16bit words in the sub-field. Currently transmitted as 4
 Community List   One or more community values as defined in section 10.4

 10.9.3.5 0x04   Jitter
   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       0x04     |      0x03    |             Jitter            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Jitter   The measure of the variability over time of the latency across a
 network measured in measured in microseconds.

Savage, et al.                  Expires August 16, 2015                    [55]

Internet-Draft                          EIGRP                     August, 2015

10.9.3.6 0x05   Quiescent Energy
   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       0x05     |        0x02   |       Q-Energy (high)        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
 |          Q-Energy (low)        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Q-Energy - Paths with higher idle (standby) energy usage will be reflected in a
 higher aggregate metric than those having lower energy usage. If present, this
 number will represent the idle power consumption expressed in milliwatts per
 kilobit.

 10.9.3.7 0x06   Energy
   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       0x06     |      0x02    |          Energy (high)        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
 |          Energy (low)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Energy - Paths with higher active energy usage will be reflected in a higher
 aggregate metric than those having lower energy usage. If present, this number
 will represent the power consumption expressed in milliwatts per kilobit.

 10.9.3.8 0x07   AddPath
 The Add Path enables EIGRP to advertise multiple best paths to adjacencies.
 There will be up to a maximum of 4 AddPath supported, where the format of the
 field will be as follows;

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       0x07    |       Offset |     AddPath (Variable Length) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+

 Offset   Number of 16bit words in the sub-field. Currently transmitted as 4

 AddPath   Length of this field will vary in length based on weather it contains
 IPv4 or IPv6 data.

 10.9.3.8.1 Addpath with IPv4 Next-hop

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       0x07    |       Offset | Next-hop Address(Upper 2 byes) |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
 | IPv4 Address (Lower 2 byes)   |       RID (Upper 2 byes)      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
 |        RID (Upper 2 byes)     | Admin Tag (Upper 2 byes)      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
 | Admin Tag (Upper 2 byes)      |Extern Protocol| Flags Field   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+

Savage, et al.                  Expires August 16, 2015                    [56]

Internet-Draft                          EIGRP                     August, 2015

 Next Hop Address   IPv4 address is represented by 4 8-bit values (total 4
 octets). If the value is zero(0), the IPv6 address from the received IPv4
 header is used as the next-hop for the route. Otherwise, the specified IPv4
 address will be used.

 Router Identifier (RID)   A 32bit number provided by the router sourcing the
 information to uniquely identify it as the source.

 Admin Tag - A 32 bit administrative tag assigned by the network. This allows a
 network administrator to filter routes based on this value.

 If the route is of type external, then 2 addition bytes will be add as follows:

 External Protocol - Defines the external protocol that this route was learned.
 See Section 10.2

 Flag Field - See Section 10.8.1

 10.9.3.8.2 Addpath with IPv6 Next-hop
   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       0x07     |       Offset |         Next-hop Address      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
 |                                                               |
 |                            (16 octets)                        |                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+|
 |                                |       RID (Upper 2 byes)     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
 |        RID (Upper 2 byes)      | Admin Tag (Upper 2 byes)     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
 | Admin Tag (Upper 2 byes)       |Extern Protocol| Flags Field |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+

 Next Hop Address - IPv6 address is represented by 8 groups of 16-bit values
 (total 16 octets). If the value is zero(0), the IPv6 address from the received
 IPv6 header is used as the next-hop for the route. Otherwise, the specified IPv6
 address will be used.

 Router Identifier (RID)   A 32bit number provided by the router sourcing the
 information to uniquely identify it as the source.

 Admin Tag - A 32 bit administrative tag assigned by the network. This allows a
 network administrator to filter routes based on this value.
 If the route is of type external, then 2 addition bytes will be add as follows:

 External Protocol - Defines the external protocol that this route was learned.
 See Section 10.2

 Flag Field - See Section 10.8.1

Savage, et al.                  Expires August 16, 2015                    [57]

Internet-Draft                          EIGRP                     August, 2015

10.9.4 Exterior Encoding
 Additional routing information so provided for destinations outside of the EIGRP
 autonomous system as follows:
   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Router Identification (RID)                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Autonomous System Number (AS)               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     External Protocol Metric                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Reserved             |Extern Protocol| Flags Field |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Router Identifier (RID)   A 32bit number provided by the router sourcing the
 information to uniquely identify it as the source.

 Autonomous System (AS)   32-bit number indicating the external autonomous system
 the sending router is a member of. If the source protocol is EIGRP, this field
 will be the [VRID|AS] pair.

 External Protocol Metric   32bit value of the metric used by the routing table
 as learned by the foreign protocol. If the External Protocol is IGRP or EIGRP,
 the value can (optionally) be 0, and the metric information is stored in the
 metric section.

 External Protocol - Defines the external protocol that this route was learned.
 See Section 10.2

 Flag Field - See Section 10.8.1

 10.9.5 Destination Encoding
 Destination information is encoded in Multi-Protocol packets in the same manner
 as used by Classic TLVs. This is accomplished by using a counter to indicate
 how many significant bits are present in the variable length address field
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Subnet Mask    |    Destination Address (variable length      |
 | Bit Count      |         ((Bit Count - 1) / 8) + 1            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Subnet Mask Bit Count   8-bit value used to indicate the number of bits in the
 subnet mask. A value of 0 indicates the default network and no address is
 present.

 Destination Address   A variable length field used o carry the destination
 address. The length is determined by the number of consecutive bits in the
 destination address, rounded up to the nearest octet boundary, determines the
 length of the address.

Savage, et al.                  Expires August 16, 2015                    [58]

Internet-Draft                          EIGRP                     August, 2015

 10.9.6 Route Information

 10.9.6.1 INTERNAL TYPE
 This TLV conveys destination information based on the IANA AFI defined in the
 TLV Header (See Section 10.9.1), and associated metric information. Routes
 advertised in this TLV are network interfaces that EIGRP is configured on as
 well as networks that are learned via other routers running EIGRP.

 10.9.6.2 EXTERNAL TYPE
 This TLV conveys destination information based on the IANA AFI defined in the
 TLV Header (See Section 10.9.1), and metric information for routes learned by
 other routing protocols that EIGRP injects into the AS. Available with this
 information is the identity of the routing protocol that created the route, the
 external metric, the AS number, an indicator if it should be marked as part of
 the EIGRP AS, and a network administrator tag used for route filtering at EIGRP
 AS boundaries.

Savage, et al.                  Expires August 16, 2015                    [59]

Internet-Draft                          EIGRP                     August, 2015

Author's Address

 Donnie V Savage
 Cisco Systems, Inc
 7025 Kit Creed Rd, RTP, NC

 Phone: 919-392-2379
 Email: dsavage@cisco.com

 Donald Slice
 Cumulus Networks
 Apex, NC

 Phone:
 Email: dslice@cumulusnetworks.com

 James Ng
 Cisco Systems, Inc
 7025 Kit Creed Rd, RTP, NC

 Phone: 919-392-2582
 Email: jamng@cisco.com

 Peter Paluch
 University of Zilina
 Univerzitna 8215/1, Zilina 01026, Slovakia

 Phone: 421-905-164432
 Email: Peter.Paluch@fri.uniza.sk

 Steven Moore
 Cisco Systems, Inc
 7025 Kit Creed Rd, RTP, NC

 Phone: 919-392-2674
 Email: smoore@cisco.com

 Russ White
 Ericsson
 Apex, NC

 Phone: 1-877-308-0993
 Email: russw@riw.us

Savage, et al.                  Expires August 16, 2015                    [60]