tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7868

 
 
 

Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)

Part 4 of 4, p. 57 to 80
Prev RFC Part

 


prevText      Top      ToC       Page 57 
6.8.  Classic Route Information TLV Types

6.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 that 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.

6.8.2.  Classic Metric Encoding

   The handling of bandwidth and delay for Classic TLVs is 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 along an
      unloaded path.  This is expressed in units of tens 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.

Top      Up      ToC       Page 58 
   MTU: The minimum MTU 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.

   Flags Field: See Section 6.8.1.

6.8.3.  Classic Exterior Encoding

   Additional routing information so provided for destinations outside
   of the EIGRP AS 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 Identifier (RID)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               External Autonomous System (AS) Number          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Administrative Tag                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    External Protocol Metric                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |Extern Protocol|  Flags Field  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   External Autonomous System (AS) Number: A 32-bit number indicating
      the external AS of which the sending router is a member.  If the
      source protocol is EIGRP, this field will be the [VRID, AS] pair.
      If the external protocol does not have an AS, other information
      can be used (for example, Cisco uses process-id for OSPF).

   Administrative 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.

Top      Up      ToC       Page 59 
   External Protocol Metric: 32-bit 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: Contains an enumerated value defined in Section
      6.2 to identify the routing protocol (external protocol)
      redistributing the route.

   Flags Field: See Section 6.8.1

6.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 to carry the
      destination address.  The length is determined by the number of
      consecutive bits in the destination address.  The formula to
      calculate the length is address-family dependent:

      IPv4: ((Bit Count - 1) / 8) + 1
      IPv6: (Bit Count == 128) ? 16 : ((x / 8) + 1)

6.8.5.  IPv4-Specific TLVs

      INTERNAL_TYPE       0x0102
      EXTERNAL_TYPE       0x0103
      COMMUNITY_TYPE      0x0104

Top      Up      ToC       Page 60 
6.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 6.8.2)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                       Destination Section                     |
   |                 IPv4 Address (variable length)                |
   |                       (see Section 6.8.4)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Vector Metric Section: The vector metrics for destinations contained
      in this TLV.  See the description of "metric encoding" in Section
      6.8.2.

   Destination Section: The network/subnet/host destination address
      being requested.  See the description of "destination" in Section
      6.8.4.

6.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.

Top      Up      ToC       Page 61 
    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 Section 6.8.3)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Vector Metric Section (see Section 6.8.2)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                       Destination Section                     |
   |                 IPv4 Address (variable length)                |
   |                       (see Section 6.8.4)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next-Hop Forwarding Address: IPv4 address represented by four 8-bit
      values (total 4 octets).  If the value is zero (0), the IPv4
      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 provided for a
      destination that is outside of the AS and that has been
      redistributed into the EIGRP.  See the description of "exterior
      encoding" in Section 6.8.3.

   Vector Metric Section: Vector metrics for destinations contained in
      this TLV.  See the description of "metric encoding" in Section
      6.8.2.

   Destination Section: The network/subnet/host destination address
      being requested.  See the description of "destination" in Section
      6.8.4.

Top      Up      ToC       Page 62 
6.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)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

   Community List: One or more 8-octet EIGRP communities, as defined in
      Section 6.4.

6.8.6.  IPv6-Specific TLVs

      INTERNAL_TYPE                 0x0402
      EXTERNAL_TYPE                 0x0403
      COMMUNITY_TYPE                0x0404

Top      Up      ToC       Page 63 
6.8.6.1.  IPv6 INTERNAL_TYPE

   This TLV conveys the 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 6.8.2)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                       Destination Section                     |
   |                 IPv6 Address (variable length)                |
   |                       (see Section 6.8.4)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next-Hop Forwarding Address: This IPv6 address is represented by
      eight 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.

   Vector Metric Section: Vector metrics for destinations contained in
      this TLV.  See the description of "metric encoding" in Section
      6.8.2.

   Destination Section: The network/subnet/host destination address
      being requested.  See the description of "destination" in Section
      6.8.4.

6.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
   topology.  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.

Top      Up      ToC       Page 64 
    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 6.8.3)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Vector Metric Section (see Section 6.8.2)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                        Destination Section                    |
   |                 IPv6 Address (variable length)                |
   |                       (see Section 6.8.4)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next-Hop Forwarding Address: IPv6 address is represented by eight
      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 provided for a
      destination that is outside of the AS and that has been
      redistributed into the EIGRP.  See the description of "exterior
      encoding" in Section 6.8.3.

   Vector Metric Section: vector metrics for destinations contained in
      this TLV.  See the description of "metric encoding" in Section
      6.8.2.

   Destination Section: The network/subnet/host destination address
      being requested.  See the description of "destination" in Section
      6.8.4.

Top      Up      ToC       Page 65 
6.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x04     |       0x04    |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                            Destination                        |
   |                            (16 octets)                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved           |       Community Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Community List                        |
   |                        (variable length)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Community Length: A 2-octet unsigned number that indicates the length
      of the Community List.  The length does not include the IPv6
      Address, Reserved, or Length fields.

   Community List: One or more 8-octet EIGRP communities, as defined in
      Section 6.4.

Top      Up      ToC       Page 66 
6.9.  Multiprotocol 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                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Acknowledgment Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Virtual Router ID             |   Autonomous System Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      TLV Header Encoding                      |
   |                      (see Section 6.9.1)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Wide Metric Encoding                    |
   |                       (see Section 6.9.2)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Destination Descriptor                  |
   |                         (variable length)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.9.1.  TLV Header Encoding

   There has been a long-standing requirement for EIGRP to support
   routing technologies, such as multi-topologies, and to 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, it 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)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 67 
   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 32-bit number provided by the router
      sourcing the information to uniquely identify it as the source.

6.9.2.  Wide Metric Encoding

   Multiprotocol TLVs 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 as follows:

   Offset: Number of 16-bit words in the Extended Attribute section that
      are used to determine the start of the destination information.  A
      value of zero indicates no Extended Attributes are attached.

Top      Up      ToC       Page 68 
   Priority: Priority of the prefix when processing a 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 value 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 MTU 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; a value of
      0xFFFFFFFFFFFF indicates an unreachable route.

   Reserved: Transmitted as 0x0000.

   Opaque Flags: 16-bit protocol-specific flags.  Values currently
      defined by Cisco are:

          OPAQUE_SRCWD    0x01   Route Source Withdraw
          OPAQUE_CD       0x02   Candidate default route
          OPAQUE_ACTIVE   0x04   Route is currently in active state
          OPAQUE_REPL     0x08   Route is replicated from another VRF

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

6.9.3.  Extended Metrics

   Extended metrics allow for extensibility of the vector metrics in a
   manner similar to RFC 6390 [11].  Each Extended metric shall consist
   of a header identifying the type (Opcode) and the length (Offset)
   followed by application-specific information.  Extended metric values
   not understood must be treated as opaque and passed along with the
   associated route.

Top      Up      ToC       Page 69 
   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 16-bit words in the application-specific
      information.  Offset does not include the length of the Opcode or
      Offset.

   Data: Zero or more octets of data as defined by Opcode.

6.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.

Top      Up      ToC       Page 70 
6.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                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved: Transmitted as 0x0000

   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.

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

6.9.3.3.  0x02 - Administrator Tag

   EIGRP administrative tag does not alter the path decision-making
   process.  Routers can set a tag value on a route and use the flags to
   apply specific routing polices within their network.

    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.

Top      Up      ToC       Page 71 
6.9.3.4.  0x03 - Community List

   EIGRP communities themselves do not alter the path decision-making
   process, communities can be used as flags in order to mark a set of
   routes.  Upstream routers can then use these flags to apply specific
   routing polices within their network.

    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 16-bit words in the sub-field.

   Community List: One or more 8-octet EIGRP communities, as defined in
      Section 6.4.

6.9.3.5.  0x04 - Jitter

   (Optional) EIGRP can carry one-way Jitter in networks that carry UDP
   traffic if the node is capable of measuring UDP Jitter.  The Jitter
   reported to will be averaged with any existing Jitter data and
   include in the route updates.  If no Jitter value is reported by the
   peer for a given destination, EIGRP will use the locally collected
   value.

    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.

6.9.3.6.  0x05 - Quiescent Energy

   (Optional) EIGRP can carry energy usage by nodes in networks if the
   node is capable of measuring energy.  The Quiescent Energy reported
   will be added to any existing energy data and include in the route
   updates.  If no energy data is reported by the peer for a given
   destination, EIGRP will use the locally collected value.

Top      Up      ToC       Page 72 
    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.

6.9.3.7.  0x06 - Energy

   (Optional) EIGRP can carry energy usage by nodes in networks if the
   node is capable of measuring energy.  The active Energy reported will
   be added to any existing energy data and include in the route
   updates.  If no energy data is reported by the peer for a given
   destination, EIGRP will use the locally collected value.

    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.

6.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 four AddPaths
   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 16-bit words in the sub-field.

Top      Up      ToC       Page 73 
   AddPath: Length of this field will vary in length based on whether it
      contains IPv4 or IPv6 data.

6.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 Addr. (Upper 2 bytes)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv4 Address (Lower 2 bytes)  |       RID (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        RID (Upper 2 bytes)    | Admin Tag (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Admin Tag (Upper 2 bytes)     |Extern Protocol| Flags Field   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next-Hop Address: An IPv4 address represented by four 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 32-bit 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 two additional bytes will be
   added as follows:

   External Protocol: Contains an enumerated value defined in Section
      6.2 to identify the routing protocol (external protocol)
      redistributing the route.

   Flags Field: See Section 6.8.1.

Top      Up      ToC       Page 74 
6.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: An IPv6 address represented by eight 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 32-bit 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 two addition bytes
      will be added as follows:

   External Protocol: Contains an enumerated value defined in Section
      6.2 to identify the routing protocol (external protocol)
      redistributing the route.

   Flags Field: See Section 6.8.1.

Top      Up      ToC       Page 75 
6.9.4.  Exterior Encoding

   Additional routing information provided for destinations outside of
   the EIGRP AS 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 Identifier (RID)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            External Autonomous System (AS) Number             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     External Protocol Metric                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved             |Extern Protocol| Flags Field |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   External Autonomous System (AS) Number: A 32-bit number indicating
      the external AS of which the sending router is a member.  If the
      source protocol is EIGRP, this field will be the [VRID, AS] pair.
      If the external protocol does not have an AS, other information
      can be used (for example, Cisco uses process-id for OSPF).

   External Protocol Metric: A 32-bit 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: Contains an enumerated value defined in Section
      6.2 to identify the routing protocol (external protocol)
      redistributing the route.

   Flags Field: See Section 6.8.1.

Top      Up      ToC       Page 76 
6.9.5.  Destination Encoding

   Destination information is encoded in Multiprotocol packets in the
   same manner 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 to carry the
      destination address.  The length is determined by the number of
      consecutive bits in the destination address.  The formula to
      calculate the length is address-family dependent:

      IPv4: ((Bit Count - 1) / 8) + 1
      IPv6: (Bit Count == 128) ? 16 : ((x / 8) + 1)

6.9.6.  Route Information

6.9.6.1.  INTERNAL TYPE

   This TLV conveys destination information based on the IANA AFI
   defined in the TLV Header (see Section 6.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.

6.9.6.2.  EXTERNAL TYPE

   This TLV conveys destination information based on the IANA AFI
   defined in the TLV Header (see Section 6.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.

Top      Up      ToC       Page 77 
7.  Security Considerations

   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 heavyweight 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 through the use of MD5 or SHA2-256
   [6].

8.  IANA Considerations

   This document serves as the sole reference for two multicast
   addresses: 224.0.0.10 for IPv4 "EIGRP Routers" [13] and
   FF02:0:0:0:0:0:0:A for IPv6 "EIGRP Routers" [14].  It also serves as
   assignment for protocol number 88 (EIGRP) [15].

9.  References

9.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
        <http://www.rfc-editor.org/info/rfc2119>.

   [2]  Garcia-Luna-Aceves, J.J., "A Unified Approach to Loop-Free
        Routing Using Distance Vectors or Link States", SIGCOMM '89,
        Symposium proceedings on Communications architectures &
        protocols, Volume 19, pages 212-223, ACM
        089791-332-9/89/0009/0212, DOI 10.1145/75247.75268, 1989.

   [3]  Garcia-Luna-Aceves, J.J., "Loop-Free Routing using Diffusing
        Computations", Network Information Systems Center, SRI
        International, appeared in IEEE/ACM Transactions on Networking,
        Vol. 1, No. 1, DOI 10.1109/90.222913, 1993.

   [4]  Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended
        Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014,
        <http://www.rfc-editor.org/info/rfc7153>.

Top      Up      ToC       Page 78 
   [5]  Narten, T., "Assigning Experimental and Testing Numbers
        Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692,
        January 2004, <http://www.rfc-editor.org/info/rfc3692>.

   [6]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and
        HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May
        2007, <http://www.rfc-editor.org/info/rfc4868>.

   [7]  Deering, S., "Host extensions for IP multicasting", STD 5,
        RFC 1112, DOI 10.17487/RFC1112, August 1989,
        <http://www.rfc-editor.org/info/rfc1112>.

   [8]  Postel, J., "Internet Protocol", STD 5, RFC 791,
        DOI 10.17487/RFC0791, September 1981,
        <http://www.rfc-editor.org/info/rfc791>.

   [9]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998,
        <http://www.rfc-editor.org/info/rfc2460>.

9.2.  Informative References

   [10] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
        DOI 10.17487/RFC2328, April 1998,
        <http://www.rfc-editor.org/info/rfc2328>.

   [11] Clark, A. and B. Claise, "Guidelines for Considering New
        Performance Metric Development", BCP 170, RFC 6390,
        DOI 10.17487/RFC6390, October 2011,
        <http://www.rfc-editor.org/info/rfc6390>.

   [12] IANA, "Address Family Numbers",
        <http://www.iana.org/assignments/address-family-numbers>.

   [13] IANA, "IPv4 Multicast Address Space Registry",
        <http://www.iana.org/assignments/multicast-addresses>.

   [14] IANA, "IPv6 Multicast Address Space Registry",
        <http://www.iana.org/assignments/ipv6-multicast-addresses>.

   [15] IANA, "Protocol Numbers",
        <http://www.iana.org/assignments/protocol-numbers>.

Top      Up      ToC       Page 79 
Acknowledgments

   Thank you goes to Dino Farinacci, Bob Albrightson, and Dave Katz.
   Their significant accomplishments towards the design and development
   of the EIGRP 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 led the
   evolution of EIGRP over the past 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, we would like to personally recognize the teams that
   created open source versions of EIGRP:

   o  Linux implementation developed by the Quagga team: Jan Janovic,
      Matej Perina, Peter Orsag, and Peter Paluch.

   o  BSD implementation developed and released by Renato Westphal.

Top      Up      ToC       Page 80 
Authors' Addresses

   Donnie V. Savage
   Cisco Systems, Inc.
   7025 Kit Creek Rd., RTP,
   Morrisville, NC 27560
   United States
   Phone: 919-392-2379
   Email: dsavage@cisco.com

   James Ng
   Cisco Systems, Inc.
   7025 Kit Creek Rd., RTP,
   Morrisville, NC 27560
   United States
   Phone: 919-392-2582
   Email: jamng@cisco.com

   Steven Moore
   Cisco Systems, Inc.
   7025 Kit Creek Rd., RTP,
   Morrisville, NC 27560
   United States
   Phone: 408-895-2031
   Email: smoore@cisco.com

   Donald Slice
   Cumulus Networks
   Apex, NC
   United States
   Email: dslice@cumulusnetworks.com

   Peter Paluch
   University of Zilina
   Univerzitna 8215/1, Zilina 01026
   Slovakia
   Phone: 421-905-164432
   Email: Peter.Paluch@fri.uniza.sk

   Russ White
   LinkedIn
   Apex, NC
   United States
   Phone: 1-877-308-0993
   Email: russw@riw.us