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]