[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Draft-minnear-igrpng-00.txt                  R. Minnear/Ipsilon Networks
                                              R. Hinden/Ipsilon Networks
                                                           November 1996

                            IGRPng for IPv6

Abstract

   This document defines a routing protocol for an IPv6 internet.  It is
   based on protocols and algorithms currently in wide use in the IPv4
   Internet.

   This specification represents a new version of the Inter-Gateway
   Routing Protocol (IGRP) for use with IPv6 and other protocols.


Status of this Document

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

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

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).


Acknowledgments

   This document is a modified version of the RIPng specification,
   written by Gary Malkin and Robert Minnear [1].












Minnear et al               Expires: 11May97                    [Page 1]


Internet Draft                   IGRPng                    November 1996


                             Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Differences from the Basic Bellman-Ford Algorithm  . . . . .  4
   1.2   Differences from RIPng . . . . . . . . . . . . . . . . . . .  4
   1.3   Differences from IGRP  . . . . . . . . . . . . . . . . . . .  5
   2.  Protocol Specification . . . . . . . . . . . . . . . . . . . .  6
   2.1   Message Format . . . . . . . . . . . . . . . . . . . . . . .  8
   2.1.1   Next-Hop . . . . . . . . . . . . . . . . . . . . . . . . . 12
   2.2   The Default Route  . . . . . . . . . . . . . . . . . . . . . 13
   2.3   Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   2.3.1   Default Values . . . . . . . . . . . . . . . . . . . . . . 15
   2.4   Input Processing . . . . . . . . . . . . . . . . . . . . . . 16
   2.4.1   Request Messages . . . . . . . . . . . . . . . . . . . . . 16
   2.4.2   Update Messages  . . . . . . . . . . . . . . . . . . . . . 16
   2.5   Output Processing  . . . . . . . . . . . . . . . . . . . . . 20
   2.5.1   Triggered Updates  . . . . . . . . . . . . . . . . . . . . 20
   2.5.2   Generating Update Messages . . . . . . . . . . . . . . . . 21
   2.6   Stability Features . . . . . . . . . . . . . . . . . . . . . 22
   2.6.1   Route Hold-downs . . . . . . . . . . . . . . . . . . . . . 22
   2.6.2   Triggered Updates  . . . . . . . . . . . . . . . . . . . . 23
   2.6.3   Split Horizon  . . . . . . . . . . . . . . . . . . . . . . 23
   2.6.4   Route Poisoning  . . . . . . . . . . . . . . . . . . . . . 24
   3.  Control Functions  . . . . . . . . . . . . . . . . . . . . . . 24
   3.1   Required Control Functions . . . . . . . . . . . . . . . . . 24
   3.2   Optional Control Functions . . . . . . . . . . . . . . . . . 24
   4.  Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 26
   References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28





















Minnear et al               Expires: 11May97                    [Page 2]


Internet Draft                   IGRPng                    November 1996


1. Introduction

   This document contains a specification for a routing protocol based
   on the Bellman-Ford (or distance vector) algorithm.  Protocols based
   on this algorithm have been used for routing computations in computer
   networks since the early days of the ARPANET.

   In a very large network, such as the Internet, it is unlikely that a
   single routing protocol will be used for the entire network.  Rather,
   the network will be organized as a collection of Autonomous Systems
   (AS), each of which will, in general, be administered by a single
   entity.  Each AS will have its own routing technology, which may
   differ among AS's.  The routing protocol used within an AS is
   referred to as an Interior Gateway Protocol (IGP).  A separate
   protocol, called an Exterior Gateway Protocol (EGP), is used to
   transfer routing information among the AS's.  IGRPng is designed to
   work as an IGP in moderate to large size AS's running IPv6.  IGRPng
   is not suited for very large complex networks.  In these cases, OSPF
   is a better routing protocol.

   IGRPng is one of a class of algorithms known as Distance Vector
   algorithms.  The earliest known description of this class of
   algorithms is in Ford and Fulkerson [2].  Because of this, they are
   sometimes known as Ford-Fulkerson algorithms.  The term Bellman-Ford
   is also used, and derives from the fact that the formulation is based
   on Bellman's equation [3].  The presentation in this document is
   closely based on [4].  For an introduction to the theory of routing
   algorithms, see [5].  The basic algorithms used by this protocol were
   used in computer routing as early as 1969 in the ARPANET.  However,
   the specific ancestry of this protocol is within the Xerox network
   protocols.  The PUP protocols [6] used the Gateway Information
   Protocol to exchange routing information.  A somewhat updated version
   of this protocol was adopted for the Xerox Network Systems (XNS)
   architecture, with the name Routing Information Protocol (RIP) [7].
   Berkeley's RIP is largely the same as the XNS Routing Information
   Protocol, with XNS addresses replaced by a more general address
   format capable of handling IPv4 and other types of address, and with
   routing updates limited to one every 30 seconds.  IGRP is a
   modification of Berkeley's RIP and Dave Mills's Hello [8] to handle
   large networks.

   IGRPng incorporates many of the useful features of IGRP.
   Specifically it is designed to provide stable routing in large
   networks.  This stability is achieved by preventing routing loops
   from occurring (even as transients).  IGRPng uses a vector of metrics
   to characterize how good a path to a destination is.  This allows
   physical characteristics to be incorporated into the routing decision
   of what path to take to a given destination.  Being able to associate



Minnear et al               Expires: 11May97                    [Page 3]


Internet Draft                   IGRPng                    November 1996


   physical characteristics with routing data helps manage complex
   configurations in large corporate networks.  IGRPng supports multiple
   paths to a single destination (i.e. equal-cost paths).  IGRPng allows
   specified routes to be considered as candidates for the default
   route, allowing the best "exterior" route to be used as the default
   route.  This feature is most useful when there are multiple exit
   points in an AS.  While this specification of IGRPng is for IPv6, the
   protocol is designed to support other address families.

1.1  Differences from the Basic Bellman-Ford Algorithm

   IGRPng, like IGRP differs from the basic Bellman-Ford algorithm in
   three substantive ways:

   - Instead of a single metric to describe a path to a destination, a
     vector of metrics representing the physical characteristics of a
     given network is used.

   - There is support for multiple equal-cost paths to a single
     destination when the paths have equivalent metrics.

   - Loop prevention measures are introduced that do not depend on
     "counting to infinity" to break loops.  These measures are designed
     to prevent routing loops from forming.

1.2  Differences from RIPng

   As mentioned above, IGRPng is primarily intended for use as an IGP in
   networks.  IGRPng however does not suffer from some of the
   limitations of RIPng.  Specifically:

   - The protocol is not limited to networks whose diameter is 15 hops.
     RIPng can only be used in networks of moderate size.  Unlike RIPng,
     IGRPng uses a vector of metrics with a wide range of values.
     Networks are configured (possibly automatically) with metric values
     representing the unloaded physical delay and bandwidth
     characteristics of the network.  The vector of metrics used by
     IGRPng gives better accuracy in computing routes than the hop-count
     metric of RIPng.  This is due in part to the fact that most
     distance vector protocols have a single metric that typically
     represents delay.  Since delay is cumulative, it does not account
     for bandwidth in a path.

   - The protocol does not depend upon "counting to infinity" to
     eliminate routing loops.  Because the range of the metrics is much
     larger than RIPng, IGRPng can not rely on "counting to infinity" to
     break routing loops.  Instead, stability measures are incorporated
     into the protocol to prevent routing loops on a small or large



Minnear et al               Expires: 11May97                    [Page 4]


Internet Draft                   IGRPng                    November 1996


     scale from forming (see section 2.6).  However, the loop prevention
     measures force the protocol to ignore new data for some time after
     certain changes.

   - IGRPng differs from RIPng in the handling of the default route.
     RIPng explicitly propagates the "default route" (e.g. 0::0/0) in
     the same manner as any other route, while IGRPng allows actual
     network routes to be marked as candidate routes for the default.
     In this way IGRPng can better accommodate multiple exit points in a
     given AS.

   - IGRPng packets are sent directly over IPv6's network layer, while
     RIPng encapsulates its packets in UDP.

   - IGRPng has a per packet address family identifier allowing IGRPng
     to operate with protocols other than IPv6.

1.3  Differences from IGRP

   IGRP has been in wide deployment for a number of years and there is a
   large amount of operational experience with it.  Some features of the
   protocol proved not to be useful while others introduced instability
   in the routing tables.  IGRPng has omitted some of these features of
   IGRP:

   - Variance is not supported.  Variance provided the ability to have
     multiple "roughly-equal" cost paths.  While the concept is useful,
     in practice it is easily possible to configure permanent routing
     loops.

   - The equivalent concept of IPv4 Type of Service (TOS) was not
     carried forward to IPv6.  Also, TOS routing was not a feature of
     IGRP that was commonly utilized in practice.  Therefore, IGRPng has
     no support for TOS based routing.

   - The load and reliability metrics are no longer present.  These
     metrics were measured values and could cause a route's metrics to
     change frequently.  In practice, they were often omitted from the
     composite metric computation.

   - Both IGRP and IGRPng trigger update packets when changes in the
     network topology are detected.  However, unlike IGRP, the update
     packet that IGRPng sends only contains those entries that have
     changed since the last update packet was sent.

   - The default value for the update timer is changed from 90 seconds
     to 30 seconds.  The other timer default values continue to be
     specified as multiples of the update timer.  While timer values



Minnear et al               Expires: 11May97                    [Page 5]


Internet Draft                   IGRPng                    November 1996


     should be configurable, the higher frequency update interval is
     justified by larger link bandwidth and motivated by a need for
     faster convergence.

   - Each packet carries an address family identifier.  This allows
     IGRPng to carry routing information for a variety of network
     protocols.

   - IGRP is a classful routing protocol and only carries three bytes of
     the IPv4 address.  The fourth byte is implied by the route type.
     IGRP defines three types of routes: interior, system, and exterior.
     The distinction between network, subnet and host routes does not
     need to be made for IGRPng because an IPv6 address prefix is
     unambiguous.  Therefore, IGRPng combines the IGRP route types of
     interior and system to a single type: interior (see section 2.2 for
     a discussion on the difference between interior and exterior).

   - IGRP defined an edition number for the routing table.  This field
     is normally ignored and is not carried forward to IGRPng.

   - The delay and bandwidth metrics have been increased from 24-bit
     quantities to 32-bit quantities.


2. Protocol Specification

   IGRPng is intended to allow routers to exchange information for
   computing routes through an IPv6-based network [9].  IGRPng is a
   distance vector protocol, as described in [5].  IGRPng should be
   implemented only in routers; IPv6 provides other mechanisms for hosts
   to discover routers [10].  Any router that uses IGRPng is assumed to
   have interfaces to two or more networks.  These are referred to as
   its directly-connected networks.  The protocol relies on access to
   certain information about each of these networks, the most important
   of which are its various metrics.  The IGRPng metrics of a network
   include the topological delay time and the bandwidth of the narrowest
   bandwidth segment of the path.  These metrics should be set based on
   the delay and bandwidth characteristics of the directly-connected
   networks (i.e. Ethernet, Fast Ethernet, FDDI, ATM, etc.).
   Implementations should allow the system administrator to set these
   metrics for each network.  In addition to the metrics, each network
   will have one or more IPv6 destination address prefix.  The methods
   used to set these parameters are not specified in this document.

   Each router that implements IGRPng is assumed to have a routing
   table.  This table has one entry for every destination that is
   reachable throughout the autonomous system operating IGRPng.  Each
   entry contains at least the following information:



Minnear et al               Expires: 11May97                    [Page 6]


Internet Draft                   IGRPng                    November 1996


   - The IPv6 prefix of the destination.

   - A vector of metrics, which represents the total cost of sending a
     datagram from the router to that destination.  These metrics
     include delay, bandwidth, hop-count, and MTU.  The delay is the sum
     of the delays associated with the networks that would be traversed
     to get to the destination.  The bandwidth is the minimum bandwidth
     of all the network segments that would be traversed.  The hop-count
     is the sum of the hop-counts of all the networks that would be
     traversed, and the MTU is the minimum MTU of all the networks that
     would be traversed.

   - The IPv6 address of the next router along the path to the
     destination (i.e., the next-hop).  If the destination is on one of
     the directly-connected networks, this item is not needed.

   - A flag to indicate that the metrics for the route have changed
     recently.  This will be referred to as the "route change flag."

   - A flag to indicate if the route is an "exterior" route (see section
     2.2 for the definition of an exterior route).

   - A flag to indicate if the route may be updated or not (i.e. a lock
     flag).  This is used for route hold-downs.

   - Various timers associated with the route.  See section 2.3 for more
     details on timers.

   The entries for the directly-connected networks are set up by the
   router using information gathered by means not specified in this
   document.  The metrics for a directly-connected network are set to
   the cost of that network.  The default cost for each metric is the
   physical characteristic associated with the directly-connected
   network (e.g. the delay and bandwidth).

   Implementors may also choose to allow the system administrator to
   enter additional routes.  These would most likely be routes to hosts
   or networks outside the scope of the routing system.  They are
   referred to as "static routes."  Entries for destinations other than
   these initial static routes are added and updated by the algorithms
   described in the following sections.

   In order for the protocol to provide complete information on routing,
   every router in the AS must participate in the protocol.  In cases
   where multiple IGPs are in use, there must be at least one router
   which can propagate routing information between the protocols.

   IGRPng also carries an AS number in each routing protocol packet:



Minnear et al               Expires: 11May97                    [Page 7]


Internet Draft                   IGRPng                    November 1996


   this can allow several routing systems to share a single link without
   interfering with each other.

2.1  Message Format

   IGRPng sends its packets directly over the IPv6 network layer.  It is
   encapsulated in one or more IPv6 headers with the Next Header field
   of the immediately encapsulating IPv6 header set to the value 9.
   IGRPng protocol packets should be given precedence over regular IPv6
   data traffic, in both sending and receiving.  Therefore, IGRPng
   routing protocol packets are sent with an IPv6 Priority field set to
   7 (Internet control traffic).  All communications intended for
   another router's IGRPng process are sent to the link-local scope all-
   igrp-routers multicast group FF02::<TBD>.

   The IGRPng packet format is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  version (1)  |   opcode (1)  |    autonomous system  (2)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   # of interior routes  (2)   |   # of exterior routes (2)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | address family identifier (2) |         checksum (2)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       must be zero (4)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                Route Table Entry 1 (32)                       ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                         ...                                   ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                Route Table Entry N (32)                       ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+











Minnear et al               Expires: 11May97                    [Page 8]


Internet Draft                   IGRPng                    November 1996


   where each IPv6 Route Table Entry (RTE) has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                        IPv6 prefix (16)                       ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | prefix len (1)| hop-count (1) |         route tag (2)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           delay (4)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         bandwidth (4)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            mtu (2)            |        must be zero (2)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The maximum number of RTEs is defined below.

   Field sizes are given in octets, as indicated in the parenthesis.
   Unless otherwise specified, fields contain binary integers, in
   network byte order, with the most significant octet first (big
   endian).  Each tick mark represents one bit.

   Every message contains an IGRPng header which consists of a version
   number, an operation code, the autonomous system number, the number
   of interior routes, the number of exterior routes, and a checksum
   covering the entire contents of the IGRPng packet.

   The VERSION identifies the version number of the protocol.  This
   document describes version 1 (see section 2.4).

   The OPCODE field is used to specify the purpose of this message.  The
   opcodes implemented in version 1 are:

   1 - REQUEST    A request for the responding system to send all or
                  part of its routing table.

   2 - UPDATE     A message containing all or part of the sender's
                  routing table.  This message may be sent in response
                  to a request, or it may be an unsolicited routing
                  update generated by the sender.

   The AUTONOMOUS SYSTEM NUMBER is used to associate the routing
   information in a packet with a given instance of IGRPng.  Routes for
   a given AS are sent only in updates for that AS.  If a router
   receives a request or an update with an AS different than its



Minnear et al               Expires: 11May97                    [Page 9]


Internet Draft                   IGRPng                    November 1996


   configured one, the update is ignored.

   The ROUTE COUNTS for the interior and exterior routes indicate the
   number of routes in each section of the update message.  RTEs are not
   distinguished by any other means.  The first section are the interior
   routes followed by the exterior routes.  Exterior routes are eligible
   to be chosen as the "route of last resort" (see section 2.2).  The
   exterior route with the best composite metric will be used in
   selecting the next-hop for the default route.  This is the only way
   in which exterior and interior routes differ.

   The packet format is intended to allow IGRPng to carry routing
   information for several different protocols.  Thus, each packet has
   an ADDRESS FAMILY IDENTIFIER to indicate what type of address is
   specified in that packet.  This differs from RIP in that the address
   family applies to all RTEs for a given packet.  The address family
   identifier for IPv6 is 2 (see Assigned Numbers [11]).  To allow for
   future enhancements, implementations are required to ignore packets
   that they do not support.  IGRPng is only suited for protocols which
   have contiguous network masks.  This document only describes routing
   for IPv6 networks.

   The CHECKSUM is an IP checksum, computed using the standard IP
   checksum algorithm.  The checksum applies to the IGRPng header and
   all RTEs contained in it.  The checksum field is set to zero when
   computing the checksum.

   For each of these message types, the remainder of the datagram
   contains a list of RTEs.  Each RTE in this list contains a
   destination prefix, the number of significant bits in the prefix, the
   delay, bandwidth, hop-count and MTU costs to reach that destination
   (metric vector), and a route tag.

   The DESTINATION PREFIX is the usual 128-bit, IPv6 address prefix
   stored as 16 octets in network byte order.  Bits beyond the prefix
   length are ignored or set to zero.

   The PREFIX LENGTH field is the length in bits of the significant part
   of the prefix (a value between 0 and 128 inclusive) starting from the
   left of the prefix.

   The DELAY field contains a value between 1 and 0xFFFFFFFF inclusive,
   specifying the current delay (in units of tens of microseconds) for
   the destination.  This provides a range of values from 10
   microseconds to approximately 12 hours. The value 0xFFFFFFFF
   (infinity), indicates that the destination is not reachable.  If the
   delay indicates that the destination is not reachable, the contents
   of the bandwidth, hop-count, and mtu fields are not defined.  The



Minnear et al               Expires: 11May97                   [Page 10]


Internet Draft                   IGRPng                    November 1996


   delay is additive from each router to the next (i.e. it is used to
   sum the cumulative delay from the router to the destination).  The
   delay represents the topological delay of the unloaded network (i.e.
   it is not a measured value).

   The HOP-COUNT field contains a value between 0 and 254 inclusive,
   specifying the current hop-count for the destination.  The value of
   255 is used to indicate that the RTE is a next-hop RTE (see section
   2.1.1).  The hop-count is also cumulative and represents the number
   of routers in a path.

   The BANDWIDTH field contains a value between 1 and 0xFFFFFFFF
   inclusive, specifying the current bandwidth (in inverse units of 1K
   bits per second scaled by 1.0e7) for the destination.  This provides
   a range of values from 2 bps to 10 Gbps.  The bandwidth is used in
   calculating the minimum bandwidth of any given network segment from
   the router to the destination.

   The MTU field contains a value between 0 and 65535 inclusive,
   specifying the current MTU (in units of bytes) for the destination.
   The MTU is used in calculating the minimum MTU of any given network
   segment from the router to the destination (i.e. the maximum IPv6
   packet size that can be sent along a path without being fragmented).
   The MTU is not currently utilized by the protocol.

   The ROUTE TAG field is an attribute assigned to a route which must be
   preserved and re-advertised with a route.  The intended use of the
   route tag is to provide a method of separating "internal" IGRPng
   routes (routes for networks within the IGRPng autonomous system) from
   "external" IGRPng routes, which may have been imported from an EGP or
   another IGP.  Note the difference between "external"/"internal" for
   route tags and "exterior"/"interior" route types for the RTEs.

   Routers supporting protocols other than IGRPng should allow the route
   tag to be configured for routes imported from different sources.  For
   example, routes imported from an EGP should be able to have their
   route tag either set to an arbitrary value, or at least to the number
   of the Autonomous System from which the routes were learned.

   Other uses of the route tag are valid, as long as all routers in the
   IGRPng autonomous system use it consistently.

   The maximum datagram size is limited by the MTU of the medium over
   which the protocol is being used.  Since an unsolicited IGRPng update
   is never propagated across a router, there is no danger of an MTU
   mismatch.  The determination of the number of RTEs which may be put
   into a given message is a function of the medium's MTU, the number of
   octets of IPv6 header information (including options and extension



Minnear et al               Expires: 11May97                   [Page 11]


Internet Draft                   IGRPng                    November 1996


   headers) preceding the IGRPng message, the size of the IGRPng header,
   and the size of an RTE.  The formula is:

               +-                                       -+
               | MTU - sizeof(IPv6_hdrs) - IGRPng_hdrlen |
   #RTEs = INT | --------------------------------------- |
               |                 RTE_size                |
               +-                                       -+

2.1.1  Next-Hop

   IGRPng uses the link-local source address of an update message as the
   next-hop address for RTEs that are installed as routes.  IGRPng also
   provides the ability to specify the immediate next-hop IPv6 address
   to which packets to a destination specified by a route table entry
   (RTE) should be forwarded in much the same way as RIP-2 [12].  In
   RIP-2, each route table entry has a next-hop field.  Including a
   next-hop field for each RTE in IGRPng would nearly double the size of
   the RTE.  Therefore, in IGRPng, the next-hop is specified by a
   special RTE and applies to all of the address RTEs following the
   next-hop RTE until the end of the message or until another next-hop
   RTE is encountered.

   A next-hop RTE is identified by a value of 0xFF in the hop-count
   field of an RTE.  The prefix field specifies the IPv6 address of the
   next hop. The prefix length, delay, bandwidth, mtu, and route tag in
   the next-hop RTE must be set to zero on sending and ignored on
   reception.

The next-hop Route Table Entry (RTE) has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        IPv6 prefix (16)                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |must be zero(1)|     0xFF      |        must be zero (2)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       must be zero (4)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       must be zero (4)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        must be zero (2)       |        must be zero (2)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Specifying a value of 0:0:0:0:0:0:0:0 in the prefix field of a next hop



Minnear et al               Expires: 11May97                   [Page 12]


Internet Draft                   IGRPng                    November 1996


RTE indicates that the next-hop address should be the originator of the
IGRPng advertisement.  Other than this special address, an address
specified as a next-hop must be a link-local address.

The purpose of the next-hop RTE is to eliminate packets being routed
through extra hops in the system.  It is particularly useful when IGRPng
is not being run on all of the routers on a network.  Note that next-hop
RTE is "advisory".  That is, if the provided information is ignored, a
possibly sub-optimal, but valid, route may be taken.  If the received
next-hop address is not a link-local address or the special address
0:0:0:0:0:0:0:0 the next-hop RTE must be ignored.  Processing continues
with the next RTE.

2.2  The Default Route

RIPng and other routing protocols propagate a default route when it is
not convenient to list every possible network in routing updates, and
when one or more routers in the system are prepared to handle traffic to
networks that are not explicitly listed. These "default routers" use the
default route as a path for all datagrams for which they have no
explicit route.

The default route for RIPng is designated by any prefix with a prefix
length of zero.  Typically the default route is specified with the
prefix 0:0:0:0:0:0:0:0, though the prefix is essentially ignored.

Instead of supporting the propagation of this pseudo route, IGRPng has
the ability to mark routes as exterior.  These "exterior" routes are
used as candidates for the default route on each router they are
received on.  The next-hop from the exterior route with the lowest
composite metric is used as the next-hop for the default route on a
given router.  Exterior routes are equivalent to interior routes with
the additional feature that only exterior routes are considered as
candidates for the default route.  This approach to the default route is
more flexible than that of RIPng (see section 4 of [13] for an example
of why this is the case).  When propagating an exterior route, its
exterior property must be preserved.

The mechanism on how to initially mark a network on a router as exterior
is left to the implementor.  In general, the system administrator should
be provided with a way to specify which directly connected networks of a
router can be advertised as exterior route entries.  If this mechanism
is used, the implementation should allow the network administrator to
choose the metrics associated with the exterior route advertisement in
the absence of full IGRPng metric information from a peer AS border
router.  This makes it possible to establish precedence among multiple
default routers.




Minnear et al               Expires: 11May97                   [Page 13]


Internet Draft                   IGRPng                    November 1996


Each IGRPng router is configured with the AS numbers of other IGRPng
peers it is willing to accept routing information from.  This feature
enables IGRPng routers to enforce routing boundaries and prevent the
propagation of routes outside their configured scope.  This is important
for controlling where exterior routes are advertised.

2.3  Timers

This section describes all events that are triggered by timers.

Every 30 seconds, the IGRPng process is awakened to send an unsolicited
Update message, containing the complete routing table (see section 2.6.3
on Split Horizon), to every neighboring router.  When there are many
routers on a single network, there is a tendency for them to synchronize
with each other such that they all issue updates at the same time.  This
can happen whenever the 30 second timer is affected by the processing
load on the system.  It is undesirable for the update messages to become
synchronized, since it can lead to unnecessary collisions on broadcast
networks (see [14] for more details).  Therefore, implementations are
required to take one of two precautions:

- The 30-second updates are triggered by a clock whose rate is not
  affected by system load or the time required to service the previous
  update timer.

- The 30-second timer is offset by a random time (+/- 0 to 15 seconds)
  each time it is set.  The offset is derived from 0.5 * the update
  period (i.e. 30).

There are two or three timers associated with each route (depending on
whether hold-downs are enabled), a "timeout", a "hold-down time" if
hold-downs are enabled, and a "garbage-collection time."  Upon
expiration of the timeout, the route is no longer valid and must not be
used to forward packets.  However, it is retained in the routing table
for a short time so that neighbors can be notified that the route has
been dropped.  If hold-downs are enabled, then until expiration of the
hold-down timer no new updates for the route are accepted, even if they
indicate reachability.  Upon expiration of the garbage-collection timer,
the route is finally removed from the routing table.

The timeout is initialized when a route is established, and any time an
update message is received for the route.  If 90 seconds elapse from the
last time the timeout was initialized, the route is considered to have
expired, and the deletion process described below begins for that route.

Deletions can occur for one of two reasons: the timeout expires, or the
delay metric is set to 0xFFFFFFFF because of an update received from the
originating router of the route (see section 2.4.2 for a discussion of



Minnear et al               Expires: 11May97                   [Page 14]


Internet Draft                   IGRPng                    November 1996


processing updates from other routers).  In either case, the following
events happen:

- The garbage-collection timer is set for 120 seconds.

- If hold-downs are enabled, the route lock flag is set to indicate that
  this entry may not be updated and the hold-down timer is set for 100
  seconds.

- The delay metric for the route is set to 0xFFFFFFFF (unreachable).
  This causes the route to be removed from service.

- The route change flag is set to indicate that this entry has been
  changed.

- The output process is signaled to send a triggered update.

Until the garbage-collection timer expires, the route is included in all
updates sent by this router.  When the garbage-collection timer expires,
the route is deleted from the routing table.

When the hold-down timer expires (if hold-downs are enabled), the route
lock flag is cleared.

Should a new route to this network be established while the garbage-
collection timer is running, the new route will replace the one that is
about to be deleted only if the route lock flag is not set.  If the
route is updated, the garbage-collection timer must be cleared.

Triggered updates also use a small timer; this is described in section
2.5.1.

2.3.1  Default Values

The timer values given in the above section are the recommended protocol
default values.  An implementation may choose to make some or all the
timer values configurable.  In this case the following guidelines should
apply:

- The route "timeout" value should be three times the update timer, if
  it is not specified.

- The "hold-down" value should be three times the update timer plus ten,
  if it is not specified.

- The "garbage-collection" value should be four times the update timer,
  if it is not specified.




Minnear et al               Expires: 11May97                   [Page 15]


Internet Draft                   IGRPng                    November 1996


- The "hold-down" value must be less than the "garbage-collection"
  value.

2.4  Input Processing

This section will describe the handling of datagrams received on the
IGRPng multicast group all-igrp-routers or a unicast address of the
router.  Processing will depend upon the value in the opcode field.
Version 1 supports only two commands: Request and Update.

2.4.1  Request Messages

A Request is used to ask the recipient to send its routing table.  There
is no equivalent per entry request semantics as in RIPng.  Normally,
Requests are sent as multicasts, by routers which have just come up and
are seeking to fill in their routing tables as quickly as possible.  A
router that receives a request directed at one if its globally valid
unicast addresses should use that unicast address as the source of the
response.  This may occur as part of monitoring a router's routing
table.

The request message must only be an IGRPng header, otherwise the message
is ignored.  Only the version, opcode, and autonomous system fields are
used.  The route count fields must be zero.  The checksum is checked as
normal.  If the message is valid, a call is made to the output process
to send the routing table to the requesting address.  The update message
generated by a request to a router's interface is the same as the normal
update message regularly sent on that interface.  Normal output
processing is done, including Split Horizon (see section 2.6.3 on Split
Horizon).  When a router first comes up, it multicasts a Request on
every connected network to get a complete routing table.  It is assumed
that these complete routing tables are to be used to update the
requestor's routing table.  For this reason, split horizon processing
must be done.

2.4.2  Update Messages

An Update can be received for one of several different reasons:

- response to a specific request
- regular update (unsolicited update)
- triggered update caused by a route change

Processing is the same no matter why the Update was generated.

Because processing of an Update may update the router's routing table,
the Update must be checked carefully for validity.  The size of the
datagram minus any IPv6 network layer headers and the IGRPng header must



Minnear et al               Expires: 11May97                   [Page 16]


Internet Draft                   IGRPng                    November 1996


be a multiple of the size of an RTE.  The sum of the interior and
exterior route counts must be the same as the actual number of RTEs in
the update message.  If either of these conditions is not true, the
datagram must be discarded.  The datagram's IPv6 source address should
be checked to see whether the datagram is from a valid neighbor and must
be a link-local address.  It is also worth checking to see whether the
update is from one of the router's own addresses.  Interfaces on
broadcast networks may receive copies of their own multicasts
immediately.  If a router processes its own output as new input,
confusion is likely, and such datagrams must be ignored.  As an
additional check, periodic advertisements must have their IPv6 header
hop-count set to 255, and inbound, multicast packets (i.e. periodic
advertisement or triggered update packets) must be examined to ensure
that the hop-count is 255.  This guarantees that a packet is from a
neighbor, because any intermediate node would have decremented the hop-
count.  Requests and their responses may still cross intermediate nodes
and therefore do not require the hop-count test to be done.

Once the datagram as a whole has been validated, process the RTEs in
order.  Again, start by doing validation.  Format errors usually
indicate misbehaving neighbors and should probably be brought to the
administrator's attention. The basic validity tests are:

- is the destination prefix of the RTE valid (e.g., not a multicast
prefix)
- is the prefix length of the RTE valid (i.e., between 0 and 128,
inclusive)

If any check fails, ignore that RTE and proceed to the next.  The error
should be logged.

There are two types of RTEs: interior and exterior.  The only difference
between the two is that exterior RTEs are used as candidates for the
default route.  Otherwise processing is the same for both types of RTEs.
Interior and exterior RTEs have no distinguishing fields, the route
counts are the only indication of which type an RTE is.  Interior routes
always proceed exterior routes.

If the delay metric for each received RTE indicates it is reachable, a
composite metric is calculated to combine the metric information (e.g.
delay, bandwidth, etc.) into a single measure of a path's "goodness".
This single composite value makes comparisons with existing routes
easier.  The smaller the composite metric the better a path is.  The
vector of metrics gives better accuracy in computing routes.  If
multiple paths have the same composite metric, traffic can be split
among the paths.

Once the entry has been validated and is reachable, the individual



Minnear et al               Expires: 11May97                   [Page 17]


Internet Draft                   IGRPng                    November 1996


metrics must first be updated to account for the metrics of the incoming
interface.  Only after the metrics are updated is the composite metric
calculated.  The metrics are updated as follows:

- delay = delay from the message + receiving interface delay
- bandwidth = MAX (bandwidth from the message, receiving interface
bandwidth)
- MTU = MIN (MTU from the message, receiving interface MTU)
- hop-count = MIN (hop-count from the message + 1, maximum hop-count)

If the MTU is set to zero, the MTU of the receiving interface is used.

Next, the composite metric is calculated according to the following
calculation:

- composite metric = K1 * bandwidth + K2 * delay

where:

K1 and K2 are weighted constants configurable in a manner not specified
by this document.  By default, K1 and K2 should be set to one.

Now, check to see whether there is already an explicit route for the
destination prefix.  If there is no such route, add this route to the
routing table, unless the delay metric is unreachable (there is no point
in adding a route which unusable).  If there is a route and it is in a
locked hold-down state, the RTE is ignored.  Adding a route to the
routing table consists of:

- Setting the destination prefix and length to those in the RTE.

- Setting the metrics to the newly calculated metrics (as described
  above).

- Set the next-hop address to be the address of the router from which
  the datagram came or the next-hop address specified by a next-hop RTE.

- Initialize the timeout for the route.  If the garbage-collection timer
  is running for this route, stop it (see section 2.3 for a discussion
  of the timers).

- Set the route change flag.

- Signal the output process to trigger an update (see section 2.5).

If there is an existing route that is not in a locked hold-down, compare
the originator of the route to the address of the router from which the
datagram was originated.  If this datagram is from the same router as



Minnear et al               Expires: 11May97                   [Page 18]


Internet Draft                   IGRPng                    November 1996


the existing route; do the following actions:

- If the new delay metric is unreachable, the deletion process begins
  for the route, which is no longer used for routing packets.  Note that
  the deletion process is started only when the delay metric is first
  set to unreachable.  If the metric was already infinity, then a new
  deletion process is not started.

- If hold-downs are enabled and the composite metric has increased by
  more than 10%, the deletion process begins for the route, which is no
  longer used for routing packets.

- If hold-downs are disabled and the hop-count has increased and the
  composite metric has increased, the deletion process begins for the
  route, which is no longer used for routing packets.

- Otherwise, reinitialize the timeout.  If the metrics are different put
  the new metrics in, and adjust the next-hop address (if necessary).

- Set the route change flag and signal the output process to send a
  triggered update.

In the above, if hold-downs are enabled the deletion process includes
marking the route as in the locked hold-down state.

If the datagram is not from the originating router and the new composite
metric is lower than the old one; do the following actions:

- Adopt the route from the datagram and reinitialize the timeout.  That
  is, put the new metrics in, and adjust the next-hop address (if
  necessary).

- Set the route change flag and signal the output process to send a
  triggered update.

If the new composite metric is the same as the old one, it is simplest
to do nothing further; but, there is a heuristic which could be applied.
Normally, it is senseless to replace a route if the new route has the
same composite metric as the existing route; this would cause the route
to bounce back and forth, which would generate an intolerable number of
triggered updates.  However, if the existing route is showing signs of
timing out, it may be better to switch to an alternative route
immediately, rather than waiting for the timeout to happen. Therefore,
if the new composite metric is the same as the old one, examine the
timeout for the existing route.  If it is at least two-thirds to the
expiration point, switch to the new route.  This heuristic is optional,
but highly recommended.




Minnear et al               Expires: 11May97                   [Page 19]


Internet Draft                   IGRPng                    November 1996


Any entry that fails these tests is ignored, as it is no better than the
current route.

2.5  Output Processing

This section describes the processing used to create update messages
that contain all or part of the routing table.  This processing may be
triggered in any of the following ways:

- By input processing, when a Request is received.  In this case, the
  Update is sent to only one destination (i.e. the unicast address of
  the requestor).

- By the regular routing update.  Every 30 seconds, an Update containing
  the whole routing table is sent to every neighboring router.

- By triggered updates.  Whenever the metrics for a route are changed,
  an update is triggered.

The processing required for a Request is described in section 2.4.1.

When an Update is to be sent to all neighbors (i.e., a regular or
triggered update), an Update message is multicast to the all-igrp-
routers multicast group, on all connected networks that support
broadcasting or are point-to-point links. IGRPng handles point-to-point
links the same as multi-access links, as multicasting is trivially
provided on such links.  Thus, one Update is prepared for each directly-
connected network, and sent to the all-igrp-routers multicast group.  In
most cases, this reaches all neighboring routers.  However, there are
some cases where this may not be enough. This may involve a network that
is not a broadcast network (e.g., the ARPANET), or a situation involving
dumb routers.  In such cases, it may be necessary to specify an actual
list of neighboring routers and send a datagram to each one explicitly.
It is left to the implementor to determine whether such a mechanism is
needed, and to define how the list is specified.

2.5.1  Triggered Updates

Triggered updates require special handling for two reasons.  First,
experience shows that triggered updates can cause excessive loads on
networks with limited capacity or networks with many routers on them.
Therefore, the protocol requires that implementors include provisions to
limit the frequency of triggered updates.  After a triggered update is
sent, a timer should be set for a random interval between 1 and 5
seconds.  If other changes that would trigger updates occur before the
timer expires, a single update is triggered when the timer expires.  The
timer is then reset to another random value between 1 and 5 seconds.
Triggered updates should be suppressed if a regular update is due by the



Minnear et al               Expires: 11May97                   [Page 20]


Internet Draft                   IGRPng                    November 1996


time the triggered update would be sent.

Second, triggered updates do not need to include the entire routing
table.  In principle, only those routes which have changed need to be
included.  Therefore messages generated as part of a triggered update
must include at least those routes that have their route change flag
set.  They may include additional routes, at the discretion of the
implementor; however, sending complete routing updates is strongly
discouraged.  When a triggered update is processed, messages should be
generated for every directly-connected network.  Split Horizon
processing is done when generating triggered updates as well as normal
updates (see section 2.6.3).  If, after Split Horizon processing for a
given network, a changed route will appear unchanged on that network the
route need not be sent.  If no routes need be sent on that network, the
update may be omitted.  Once all of the triggered updates have been
generated, the route change flags should be cleared.

If input processing is allowed while output is being generated,
appropriate interlocking must be done.  The route change flags should
not be changed as a result of processing input while a triggered update
message is being generated.

The only difference between a triggered update and other update messages
is the possible omission of routes that have not changed.  The remaining
mechanisms, described in the next section, must be applied to all
updates.

2.5.2  Generating Update Messages

This section describes how an Update message is generated for a
particular directly-connected network:

The IPv6 source address must be one of the link-local addresses of the
sending router's interface, except when replying to a unicast Request
Message from a non-local source address.  In the latter case, the source
address must be the globally valid address the request was directed to.
In the former case, it is important to use a link-local address because
the source address is put into routing tables (as the next-hop) in the
routers which receive this Update.  If an incorrect source address is
used, other routers may be unable to route datagrams.  The IPv6 hop-
count must be set to 255 to ensure routers can determine if the message
has been forwarded.  It is possible that a router may have multiple
link-local addresses for a single interface. In this case, the router
must only originate a single Update message with a source address of the
designated link-local address for a given interface.  The choice of
which link-local address to use should only change when the current
choice is no longer valid.  This is necessary because nodes receiving
Update messages use the source address to identify the sender.  If



Minnear et al               Expires: 11May97                   [Page 21]


Internet Draft                   IGRPng                    November 1996


multiple packets from the same router contain different source
addresses, nodes will assume they come from different routers, leading
to undesirable behavior.

Set the version number to the current version of IGRPng.  The version
described in this document is version 1.  Set the opcode to Update.  Set
the autonomous system to the configured number.  Set the address family
identifier to 2.  Set the bytes labeled "must be zero" to zero.  Start
filling in RTEs, keeping count of the number of interior and exterior
routes that are included.  Recall that the maximum datagram size is
limited by the network's MTU. When there is no more space in the
datagram, set the interior and exterior route counts appropriately,
compute the checksum over the entire IGRPng message, send the current
Update and start a new one.  Repeat the process until all routes have
been sent.

To fill in the RTEs, examine each route in the routing table.  If a
triggered update is being generated, only entries whose route change
flags are set need be included.  If, after Split Horizon processing, the
route should not be included, skip it.  If the route is to be included,
then the destination prefix, prefix length, and metrics are put into the
RTE.  The route tag is filled in as defined in section 2.1.  Routes must
be included in the datagram even if their metrics indicate the route is
unreachable.

2.6  Stability Features

IGRPng cannot rely on the same mechanism as RIPng for removing routing
loops (i.e. "counting to infinity").  This is due to the fact that the
range of metric values allowed in IGRPng is much larger.  Because of
this, IGRPng must be aggressive in assuring that routing loops never
form. It does this by potentially ignoring valid routing information for
some period of time.

IGRPng uses a combination of four techniques to prevent routing loops
from forming: route hold-downs, triggered updates, split horizon, and
route poisoning.  The exact technique used depends on whether hold-downs
are enabled or not.  Because networks can lose updates or have them
delayed, it is possible that invalid routing information can exist in
the network for some period of time.  Therefore, there is some
redundancy in the measures to ensure invalid routing information is
never accepted as valid.

2.6.1  Route Hold-downs

Hold-downs in IGRPng are designed to prevent routing update information
from being accepted for a route for some period of time after the route
is marked unreachable.  This is to ensure that the update is not an echo



Minnear et al               Expires: 11May97                   [Page 22]


Internet Draft                   IGRPng                    November 1996


of the route that continues to exist in the network.  The hold-down
period needs to be long enough for triggered updates to propagate
throughout the IGRPng autonomous system plus a couple of update cycles
to account for dropped updates.  If a triggered update is lost, the next
regular update cycle will restart the triggered update wave.

Routes can become unreachable for a number of reasons:

- The originator of the route marks the route as unreachable in a
  received update packet.

- The route "timeout" timer expires.

- If hold-downs are enabled and the composite metric information from
  the originator of the route has increased by more than 10%.

- If hold-downs are disabled, the composite metric has increased, and
  the hop-count has increased.  Obviously, the route is not placed in
  hold-down in this case.

2.6.2  Triggered Updates

Normal updates periodically send a router's complete routing state.
Triggered updates are used to send updates that contain information that
has recently changed (i.e. when a route is unreachable).  Triggered
updates are designed to speed the convergence of the routing in an
IGRPng autonomous system (see section 2.5.1 for more information).  The
problem with triggered updates is that packets may be dropped, corrupted
or delayed potentially delaying the convergence of the topology.

2.6.3  Split Horizon

Split Horizon is a algorithm for avoiding problems caused by including
routes in updates sent to the router from which they were learned.  This
helps avoid routing loops on a small scale (i.e. between two adjacent
routers on a network).  It also helps to keep the size of update
messages to a minimum.  The basic split horizon algorithm omits routes
learned from one neighbor in updates sent to that neighbor.  In the case
of a broadcast network, all routes learned from any neighbor on that
network are omitted from updates sent on that network.

Split Horizon with Poisoned Reverse (more simply, Poison Reverse) does
include such routes in updates, but sets their metrics to unreachable.
This is the preferred method of operation; however, implementations
should provide per-interface control allowing no horizoning, split
horizoning, or poisoned reverse to be selected.

For a theoretical discussion of Split Horizon and Poison Reverse and why



Minnear et al               Expires: 11May97                   [Page 23]


Internet Draft                   IGRPng                    November 1996


they are needed, see section 2.1.1 of [5] and section 5.2 of [13].

2.6.4  Route Poisoning

While split horizon avoids routing loops at a small scale, route
poisoning is designed to avoid loops at a large scale.  The basic idea
is that if a route's metrics increase sufficiently, the route should be
marked unreachable and placed in a hold-down state.  In the hold-down
state any updates for this route are ignored.  When hold-downs are
enabled, route poisoning can delay the adoption of new routes when an
old one fails.  Route poisoning has different behavior depending on if
hold-downs are enabled.

- If hold-downs are enabled and the composite metric information from
  the originator of the route has increased by more than 10%.

- If hold-downs are disabled, the composite metric has increased, and
  the hop-count has increased.  Obviously, the route is not placed in
  hold-down in this case.

Note, it is possible that the update is valid, but there is no way to
distinguish this case from an echo of an old update.  Therefore, a
conversative approach must be taken and the route is marked unreachable.
If valid information for a route exists, it will be utilized during a
later update.


3. Control Functions

This section describes administrative controls.  These are not part of
the protocol per se; however, experience with existing networks suggests
that they are important.

3.1  Required Control Functions

It is required that implementations have the ability to configure
whether hold-downs are enabled or disabled.  The setting of the hold-
down state influences some protocol actions and all IGRPng routers in an
AS must be configured with the same hold-down behavior.  Otherwise,
unpredictable routing may occur.  By default hold-downs should be
enabled.

3.2  Optional Control Functions

Because the reset of the control functions are not a necessary part of
the protocol, they are considered optional.  However, it is strongly
recommend that at least some of them be included in every
implementation.  These controls are intended primarily to allow IGRPng



Minnear et al               Expires: 11May97                   [Page 24]


Internet Draft                   IGRPng                    November 1996


to be connected to networks whose routing may be unstable or subject to
errors.  Here are some examples:

- It is sometimes desirable to restrict the routers from which updates
  will be accepted, or to which updates will be sent.  This is usually
  done for administrative, routing policy reasons.

- A number of sites limit the set of networks that they allow in Update
  messages.  Organization A may have a connection to organization B that
  they use for direct communication.  For security or performance
  reasons A may not be willing to give other organizations access to
  that connection.  In such a case, A should not include B's networks in
  updates that A sends to third parties.

Here are some typical controls.  Note, however, that the IGRPng protocol
does not require these or any other controls.

- A neighbor list which allows the network administrator to be able to
  define a list of neighbors for each router.  A router would accept
  update messages only from routers on its list of neighbors.  A similar
  list for target routers should also be available to the administrator.
  By default, no restrictions are defined.

- A filter for specific destinations would permit the network
  administrator to be able to specify a list of destination prefixes to
  allow or disallow.  The list would be associated with a particular
  interface in the incoming and/or outgoing directions.  Only allowed
  networks would be mentioned in Update messages going out or processed
  in Update messages coming in.  If a list of allowed prefixes is
  specified, all other prefixes are disallowed.  If a list of disallowed
  prefixes is specified, all other prefixes are allowed.  By default, no
  filters are applied.

- The ability to configure different values for the protocol timers (see
  section 2.3.1 for details).

- The ability to configure the delay, bandwidth, and mtu metrics for
  each directly connected network.

- As mention in section 2.6.3 it may be desirable to set the split
  horizon mode per interface.  The three settings are: no horizoning,
  split horizoning, or poisoned reverse.  By the default the setting
  should be split horizoning.








Minnear et al               Expires: 11May97                   [Page 25]


Internet Draft                   IGRPng                    November 1996


4. Issues

This section describes issues that have not yet been resolved:

- IGRP has a feature known as "specific split-horizon".  This occurs
  when a request is made and in replying the router only omits routes
  that use the requestor as the next-hop.  It is debatable if this
  feature is desirable in IGRP, however since IGRPng has the ability to
  include a next-hop address other than itself for a route, routers can
  provide the correct next-hop to the requestor.

- It may be desirable to change the units of the delay field to provide
  for shorter delays (e.g. 100ns).  It is for further study if the unit
  of the delay field would require the unit of the bandwidth field to
  change by the same order of magnitude.

- IGRPng has a checksum for the contents of the IGRPng packet, this does
  not protect the IPv6 header.  A pseudo checksum for the IPv6 header
  may need to be done.

- The support for multiple equal-cost paths needs to be written.

- Is there a minimum MTU to better define the range of acceptable values
  for the field?

- If hold-downs are disabled is there a possibility of a routing loop
  with some timer settings?  If so, should a maximum hop-count value be
  defined for the protocol to stop the propagation of the RTEs in
  question?


5. Security Considerations

Since IGRPng runs over IPv6, IGRPng relies on the IP Authentication
Header (see [15]) and the IP Encapsulating Security Payload (see [16])
to ensure integrity and authentication/confidentiality of routing
exchanges.


References

[1] Malkin, G., and Minnear, R., "RIPng",
    draft-ietf-rip-ripng-04.txt, August 1996

[2] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks",
    Princeton University Press, Princeton, N.J., 1962.

[3] Bellman, R. E., "Dynamic Programming", Princeton University Press,



Minnear et al               Expires: 11May97                   [Page 26]


Internet Draft                   IGRPng                    November 1996


    Princeton, N.J., 1957.

[4] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice-
    Hall, Englewood Cliffs, N.J., 1987.

[5] Hedrick, C., "Routing Information Protocol", Request For Comments
    (RFC) 1058, Rutgers University, June 1988.

[6] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M., "Pup:
    An Internetwork Architecture", IEEE Transactions on Communications,
    April 1980.

[7] Xerox Corp., "Internet Transport Protocols", Xerox System
    Integration Standard XSIS 028112, December 1981.

[8] Mills, D., "DCN Local-Network Protocols", Request For Comments (RFC)
    891, December 1983.

[9] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
    Specification", Request For Comments (RFC) 1883, January 1996.

[10] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery for IP
    Version 6 (IPv6)", draft-ietf-ipngwg-discovery-06.txt, March 1996.

[11] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", Request For Comments
    (RFC) 1700, October 1994.

[12] Malkin, G., "RIP Version 2 - Carrying Additional Information",
    Request For Comments (RFC) 1723, Xylogics, Inc., November, 1994.

[13] Hedrick, C., "An Introduction to IGRP", Center for Computers and
    Information Services, Rutgers University, August 1991.

[14] Floyd, S., and Jacobson, V., "The Synchronization of Periodic
    Routing Messages", Proceedings of ACM SIGCOMM '93, September 1993.

[15] Atkinson, R., "IP Authentication Header", Request For Comment (RFC)
    1826, Naval Research Laboratory, August 1995.

[16] Atkinson, R., "IP Encapsulating Security Payload (ESP)", Request
    For Comment (RFC) 1827, Naval Research Laboratory, August 1995.










Minnear et al               Expires: 11May97                   [Page 27]


Internet Draft                   IGRPng                    November 1996


Authors' Addresses

Robert E. Minnear
Ipsilon Networks, Inc.
232 Java Drive
Sunnyvale, CA 94089

Phone:  (408) 990-2014
EMail:  minnear@ipsilon.com

Robert M. Hinden
Ipsilon Networks, Inc.
232 Java Drive
Sunnyvale, CA 94089

Phone:  (408) 990-2004
EMail:  hinden@ipsilon.com


































Minnear et al               Expires: 11May97                   [Page 28]