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::. 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]