idnits 2.17.1 draft-minnear-igrpng-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 1996) is 10022 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Unexpected draft version: The latest known version of draft-ietf-rip-ripng is -03, but you're referring to -04. -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1883 (ref. '9') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1700 (ref. '11') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1723 (ref. '12') (Obsoleted by RFC 2453) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Draft-minnear-igrpng-00.txt R. Minnear/Ipsilon Networks 2 R. Hinden/Ipsilon Networks 3 November 1996 5 IGRPng for IPv6 7 Abstract 9 This document defines a routing protocol for an IPv6 internet. It is 10 based on protocols and algorithms currently in wide use in the IPv4 11 Internet. 13 This specification represents a new version of the Inter-Gateway 14 Routing Protocol (IGRP) for use with IPv6 and other protocols. 16 Status of this Document 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net 31 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 32 Rim). 34 Acknowledgments 36 This document is a modified version of the RIPng specification, 37 written by Gary Malkin and Robert Minnear [1]. 39 Table of Contents 41 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 42 1.1 Differences from the Basic Bellman-Ford Algorithm . . . . . 4 43 1.2 Differences from RIPng . . . . . . . . . . . . . . . . . . . 4 44 1.3 Differences from IGRP . . . . . . . . . . . . . . . . . . . 5 45 2. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6 46 2.1 Message Format . . . . . . . . . . . . . . . . . . . . . . . 8 47 2.1.1 Next-Hop . . . . . . . . . . . . . . . . . . . . . . . . . 12 48 2.2 The Default Route . . . . . . . . . . . . . . . . . . . . . 13 49 2.3 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 50 2.3.1 Default Values . . . . . . . . . . . . . . . . . . . . . . 15 51 2.4 Input Processing . . . . . . . . . . . . . . . . . . . . . . 16 52 2.4.1 Request Messages . . . . . . . . . . . . . . . . . . . . . 16 53 2.4.2 Update Messages . . . . . . . . . . . . . . . . . . . . . 16 54 2.5 Output Processing . . . . . . . . . . . . . . . . . . . . . 20 55 2.5.1 Triggered Updates . . . . . . . . . . . . . . . . . . . . 20 56 2.5.2 Generating Update Messages . . . . . . . . . . . . . . . . 21 57 2.6 Stability Features . . . . . . . . . . . . . . . . . . . . . 22 58 2.6.1 Route Hold-downs . . . . . . . . . . . . . . . . . . . . . 22 59 2.6.2 Triggered Updates . . . . . . . . . . . . . . . . . . . . 23 60 2.6.3 Split Horizon . . . . . . . . . . . . . . . . . . . . . . 23 61 2.6.4 Route Poisoning . . . . . . . . . . . . . . . . . . . . . 24 62 3. Control Functions . . . . . . . . . . . . . . . . . . . . . . 24 63 3.1 Required Control Functions . . . . . . . . . . . . . . . . . 24 64 3.2 Optional Control Functions . . . . . . . . . . . . . . . . . 24 65 4. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 66 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 26 67 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 70 1. Introduction 72 This document contains a specification for a routing protocol based 73 on the Bellman-Ford (or distance vector) algorithm. Protocols based 74 on this algorithm have been used for routing computations in computer 75 networks since the early days of the ARPANET. 77 In a very large network, such as the Internet, it is unlikely that a 78 single routing protocol will be used for the entire network. Rather, 79 the network will be organized as a collection of Autonomous Systems 80 (AS), each of which will, in general, be administered by a single 81 entity. Each AS will have its own routing technology, which may 82 differ among AS's. The routing protocol used within an AS is 83 referred to as an Interior Gateway Protocol (IGP). A separate 84 protocol, called an Exterior Gateway Protocol (EGP), is used to 85 transfer routing information among the AS's. IGRPng is designed to 86 work as an IGP in moderate to large size AS's running IPv6. IGRPng 87 is not suited for very large complex networks. In these cases, OSPF 88 is a better routing protocol. 90 IGRPng is one of a class of algorithms known as Distance Vector 91 algorithms. The earliest known description of this class of 92 algorithms is in Ford and Fulkerson [2]. Because of this, they are 93 sometimes known as Ford-Fulkerson algorithms. The term Bellman-Ford 94 is also used, and derives from the fact that the formulation is based 95 on Bellman's equation [3]. The presentation in this document is 96 closely based on [4]. For an introduction to the theory of routing 97 algorithms, see [5]. The basic algorithms used by this protocol were 98 used in computer routing as early as 1969 in the ARPANET. However, 99 the specific ancestry of this protocol is within the Xerox network 100 protocols. The PUP protocols [6] used the Gateway Information 101 Protocol to exchange routing information. A somewhat updated version 102 of this protocol was adopted for the Xerox Network Systems (XNS) 103 architecture, with the name Routing Information Protocol (RIP) [7]. 104 Berkeley's RIP is largely the same as the XNS Routing Information 105 Protocol, with XNS addresses replaced by a more general address 106 format capable of handling IPv4 and other types of address, and with 107 routing updates limited to one every 30 seconds. IGRP is a 108 modification of Berkeley's RIP and Dave Mills's Hello [8] to handle 109 large networks. 111 IGRPng incorporates many of the useful features of IGRP. 112 Specifically it is designed to provide stable routing in large 113 networks. This stability is achieved by preventing routing loops 114 from occurring (even as transients). IGRPng uses a vector of metrics 115 to characterize how good a path to a destination is. This allows 116 physical characteristics to be incorporated into the routing decision 117 of what path to take to a given destination. Being able to associate 118 physical characteristics with routing data helps manage complex 119 configurations in large corporate networks. IGRPng supports multiple 120 paths to a single destination (i.e. equal-cost paths). IGRPng allows 121 specified routes to be considered as candidates for the default 122 route, allowing the best "exterior" route to be used as the default 123 route. This feature is most useful when there are multiple exit 124 points in an AS. While this specification of IGRPng is for IPv6, the 125 protocol is designed to support other address families. 127 1.1 Differences from the Basic Bellman-Ford Algorithm 129 IGRPng, like IGRP differs from the basic Bellman-Ford algorithm in 130 three substantive ways: 132 - Instead of a single metric to describe a path to a destination, a 133 vector of metrics representing the physical characteristics of a 134 given network is used. 136 - There is support for multiple equal-cost paths to a single 137 destination when the paths have equivalent metrics. 139 - Loop prevention measures are introduced that do not depend on 140 "counting to infinity" to break loops. These measures are designed 141 to prevent routing loops from forming. 143 1.2 Differences from RIPng 145 As mentioned above, IGRPng is primarily intended for use as an IGP in 146 networks. IGRPng however does not suffer from some of the 147 limitations of RIPng. Specifically: 149 - The protocol is not limited to networks whose diameter is 15 hops. 150 RIPng can only be used in networks of moderate size. Unlike RIPng, 151 IGRPng uses a vector of metrics with a wide range of values. 152 Networks are configured (possibly automatically) with metric values 153 representing the unloaded physical delay and bandwidth 154 characteristics of the network. The vector of metrics used by 155 IGRPng gives better accuracy in computing routes than the hop-count 156 metric of RIPng. This is due in part to the fact that most 157 distance vector protocols have a single metric that typically 158 represents delay. Since delay is cumulative, it does not account 159 for bandwidth in a path. 161 - The protocol does not depend upon "counting to infinity" to 162 eliminate routing loops. Because the range of the metrics is much 163 larger than RIPng, IGRPng can not rely on "counting to infinity" to 164 break routing loops. Instead, stability measures are incorporated 165 into the protocol to prevent routing loops on a small or large 166 scale from forming (see section 2.6). However, the loop prevention 167 measures force the protocol to ignore new data for some time after 168 certain changes. 170 - IGRPng differs from RIPng in the handling of the default route. 171 RIPng explicitly propagates the "default route" (e.g. 0::0/0) in 172 the same manner as any other route, while IGRPng allows actual 173 network routes to be marked as candidate routes for the default. 174 In this way IGRPng can better accommodate multiple exit points in a 175 given AS. 177 - IGRPng packets are sent directly over IPv6's network layer, while 178 RIPng encapsulates its packets in UDP. 180 - IGRPng has a per packet address family identifier allowing IGRPng 181 to operate with protocols other than IPv6. 183 1.3 Differences from IGRP 185 IGRP has been in wide deployment for a number of years and there is a 186 large amount of operational experience with it. Some features of the 187 protocol proved not to be useful while others introduced instability 188 in the routing tables. IGRPng has omitted some of these features of 189 IGRP: 191 - Variance is not supported. Variance provided the ability to have 192 multiple "roughly-equal" cost paths. While the concept is useful, 193 in practice it is easily possible to configure permanent routing 194 loops. 196 - The equivalent concept of IPv4 Type of Service (TOS) was not 197 carried forward to IPv6. Also, TOS routing was not a feature of 198 IGRP that was commonly utilized in practice. Therefore, IGRPng has 199 no support for TOS based routing. 201 - The load and reliability metrics are no longer present. These 202 metrics were measured values and could cause a route's metrics to 203 change frequently. In practice, they were often omitted from the 204 composite metric computation. 206 - Both IGRP and IGRPng trigger update packets when changes in the 207 network topology are detected. However, unlike IGRP, the update 208 packet that IGRPng sends only contains those entries that have 209 changed since the last update packet was sent. 211 - The default value for the update timer is changed from 90 seconds 212 to 30 seconds. The other timer default values continue to be 213 specified as multiples of the update timer. While timer values 214 should be configurable, the higher frequency update interval is 215 justified by larger link bandwidth and motivated by a need for 216 faster convergence. 218 - Each packet carries an address family identifier. This allows 219 IGRPng to carry routing information for a variety of network 220 protocols. 222 - IGRP is a classful routing protocol and only carries three bytes of 223 the IPv4 address. The fourth byte is implied by the route type. 224 IGRP defines three types of routes: interior, system, and exterior. 225 The distinction between network, subnet and host routes does not 226 need to be made for IGRPng because an IPv6 address prefix is 227 unambiguous. Therefore, IGRPng combines the IGRP route types of 228 interior and system to a single type: interior (see section 2.2 for 229 a discussion on the difference between interior and exterior). 231 - IGRP defined an edition number for the routing table. This field 232 is normally ignored and is not carried forward to IGRPng. 234 - The delay and bandwidth metrics have been increased from 24-bit 235 quantities to 32-bit quantities. 237 2. Protocol Specification 239 IGRPng is intended to allow routers to exchange information for 240 computing routes through an IPv6-based network [9]. IGRPng is a 241 distance vector protocol, as described in [5]. IGRPng should be 242 implemented only in routers; IPv6 provides other mechanisms for hosts 243 to discover routers [10]. Any router that uses IGRPng is assumed to 244 have interfaces to two or more networks. These are referred to as 245 its directly-connected networks. The protocol relies on access to 246 certain information about each of these networks, the most important 247 of which are its various metrics. The IGRPng metrics of a network 248 include the topological delay time and the bandwidth of the narrowest 249 bandwidth segment of the path. These metrics should be set based on 250 the delay and bandwidth characteristics of the directly-connected 251 networks (i.e. Ethernet, Fast Ethernet, FDDI, ATM, etc.). 252 Implementations should allow the system administrator to set these 253 metrics for each network. In addition to the metrics, each network 254 will have one or more IPv6 destination address prefix. The methods 255 used to set these parameters are not specified in this document. 257 Each router that implements IGRPng is assumed to have a routing 258 table. This table has one entry for every destination that is 259 reachable throughout the autonomous system operating IGRPng. Each 260 entry contains at least the following information: 262 - The IPv6 prefix of the destination. 264 - A vector of metrics, which represents the total cost of sending a 265 datagram from the router to that destination. These metrics 266 include delay, bandwidth, hop-count, and MTU. The delay is the sum 267 of the delays associated with the networks that would be traversed 268 to get to the destination. The bandwidth is the minimum bandwidth 269 of all the network segments that would be traversed. The hop-count 270 is the sum of the hop-counts of all the networks that would be 271 traversed, and the MTU is the minimum MTU of all the networks that 272 would be traversed. 274 - The IPv6 address of the next router along the path to the 275 destination (i.e., the next-hop). If the destination is on one of 276 the directly-connected networks, this item is not needed. 278 - A flag to indicate that the metrics for the route have changed 279 recently. This will be referred to as the "route change flag." 281 - A flag to indicate if the route is an "exterior" route (see section 282 2.2 for the definition of an exterior route). 284 - A flag to indicate if the route may be updated or not (i.e. a lock 285 flag). This is used for route hold-downs. 287 - Various timers associated with the route. See section 2.3 for more 288 details on timers. 290 The entries for the directly-connected networks are set up by the 291 router using information gathered by means not specified in this 292 document. The metrics for a directly-connected network are set to 293 the cost of that network. The default cost for each metric is the 294 physical characteristic associated with the directly-connected 295 network (e.g. the delay and bandwidth). 297 Implementors may also choose to allow the system administrator to 298 enter additional routes. These would most likely be routes to hosts 299 or networks outside the scope of the routing system. They are 300 referred to as "static routes." Entries for destinations other than 301 these initial static routes are added and updated by the algorithms 302 described in the following sections. 304 In order for the protocol to provide complete information on routing, 305 every router in the AS must participate in the protocol. In cases 306 where multiple IGPs are in use, there must be at least one router 307 which can propagate routing information between the protocols. 309 IGRPng also carries an AS number in each routing protocol packet: 311 this can allow several routing systems to share a single link without 312 interfering with each other. 314 2.1 Message Format 316 IGRPng sends its packets directly over the IPv6 network layer. It is 317 encapsulated in one or more IPv6 headers with the Next Header field 318 of the immediately encapsulating IPv6 header set to the value 9. 319 IGRPng protocol packets should be given precedence over regular IPv6 320 data traffic, in both sending and receiving. Therefore, IGRPng 321 routing protocol packets are sent with an IPv6 Priority field set to 322 7 (Internet control traffic). All communications intended for 323 another router's IGRPng process are sent to the link-local scope all- 324 igrp-routers multicast group FF02::. 326 The IGRPng packet format is: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | version (1) | opcode (1) | autonomous system (2) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | # of interior routes (2) | # of exterior routes (2) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | address family identifier (2) | checksum (2) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | must be zero (4) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 ~ Route Table Entry 1 (32) ~ 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 344 ~ ... ~ 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 ~ Route Table Entry N (32) ~ 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 where each IPv6 Route Table Entry (RTE) has the following format: 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 ~ IPv6 prefix (16) ~ 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | prefix len (1)| hop-count (1) | route tag (2) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | delay (4) | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | bandwidth (4) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | mtu (2) | must be zero (2) | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 The maximum number of RTEs is defined below. 372 Field sizes are given in octets, as indicated in the parenthesis. 373 Unless otherwise specified, fields contain binary integers, in 374 network byte order, with the most significant octet first (big 375 endian). Each tick mark represents one bit. 377 Every message contains an IGRPng header which consists of a version 378 number, an operation code, the autonomous system number, the number 379 of interior routes, the number of exterior routes, and a checksum 380 covering the entire contents of the IGRPng packet. 382 The VERSION identifies the version number of the protocol. This 383 document describes version 1 (see section 2.4). 385 The OPCODE field is used to specify the purpose of this message. The 386 opcodes implemented in version 1 are: 388 1 - REQUEST A request for the responding system to send all or 389 part of its routing table. 391 2 - UPDATE A message containing all or part of the sender's 392 routing table. This message may be sent in response 393 to a request, or it may be an unsolicited routing 394 update generated by the sender. 396 The AUTONOMOUS SYSTEM NUMBER is used to associate the routing 397 information in a packet with a given instance of IGRPng. Routes for 398 a given AS are sent only in updates for that AS. If a router 399 receives a request or an update with an AS different than its 400 configured one, the update is ignored. 402 The ROUTE COUNTS for the interior and exterior routes indicate the 403 number of routes in each section of the update message. RTEs are not 404 distinguished by any other means. The first section are the interior 405 routes followed by the exterior routes. Exterior routes are eligible 406 to be chosen as the "route of last resort" (see section 2.2). The 407 exterior route with the best composite metric will be used in 408 selecting the next-hop for the default route. This is the only way 409 in which exterior and interior routes differ. 411 The packet format is intended to allow IGRPng to carry routing 412 information for several different protocols. Thus, each packet has 413 an ADDRESS FAMILY IDENTIFIER to indicate what type of address is 414 specified in that packet. This differs from RIP in that the address 415 family applies to all RTEs for a given packet. The address family 416 identifier for IPv6 is 2 (see Assigned Numbers [11]). To allow for 417 future enhancements, implementations are required to ignore packets 418 that they do not support. IGRPng is only suited for protocols which 419 have contiguous network masks. This document only describes routing 420 for IPv6 networks. 422 The CHECKSUM is an IP checksum, computed using the standard IP 423 checksum algorithm. The checksum applies to the IGRPng header and 424 all RTEs contained in it. The checksum field is set to zero when 425 computing the checksum. 427 For each of these message types, the remainder of the datagram 428 contains a list of RTEs. Each RTE in this list contains a 429 destination prefix, the number of significant bits in the prefix, the 430 delay, bandwidth, hop-count and MTU costs to reach that destination 431 (metric vector), and a route tag. 433 The DESTINATION PREFIX is the usual 128-bit, IPv6 address prefix 434 stored as 16 octets in network byte order. Bits beyond the prefix 435 length are ignored or set to zero. 437 The PREFIX LENGTH field is the length in bits of the significant part 438 of the prefix (a value between 0 and 128 inclusive) starting from the 439 left of the prefix. 441 The DELAY field contains a value between 1 and 0xFFFFFFFF inclusive, 442 specifying the current delay (in units of tens of microseconds) for 443 the destination. This provides a range of values from 10 444 microseconds to approximately 12 hours. The value 0xFFFFFFFF 445 (infinity), indicates that the destination is not reachable. If the 446 delay indicates that the destination is not reachable, the contents 447 of the bandwidth, hop-count, and mtu fields are not defined. The 448 delay is additive from each router to the next (i.e. it is used to 449 sum the cumulative delay from the router to the destination). The 450 delay represents the topological delay of the unloaded network (i.e. 451 it is not a measured value). 453 The HOP-COUNT field contains a value between 0 and 254 inclusive, 454 specifying the current hop-count for the destination. The value of 455 255 is used to indicate that the RTE is a next-hop RTE (see section 456 2.1.1). The hop-count is also cumulative and represents the number 457 of routers in a path. 459 The BANDWIDTH field contains a value between 1 and 0xFFFFFFFF 460 inclusive, specifying the current bandwidth (in inverse units of 1K 461 bits per second scaled by 1.0e7) for the destination. This provides 462 a range of values from 2 bps to 10 Gbps. The bandwidth is used in 463 calculating the minimum bandwidth of any given network segment from 464 the router to the destination. 466 The MTU field contains a value between 0 and 65535 inclusive, 467 specifying the current MTU (in units of bytes) for the destination. 468 The MTU is used in calculating the minimum MTU of any given network 469 segment from the router to the destination (i.e. the maximum IPv6 470 packet size that can be sent along a path without being fragmented). 471 The MTU is not currently utilized by the protocol. 473 The ROUTE TAG field is an attribute assigned to a route which must be 474 preserved and re-advertised with a route. The intended use of the 475 route tag is to provide a method of separating "internal" IGRPng 476 routes (routes for networks within the IGRPng autonomous system) from 477 "external" IGRPng routes, which may have been imported from an EGP or 478 another IGP. Note the difference between "external"/"internal" for 479 route tags and "exterior"/"interior" route types for the RTEs. 481 Routers supporting protocols other than IGRPng should allow the route 482 tag to be configured for routes imported from different sources. For 483 example, routes imported from an EGP should be able to have their 484 route tag either set to an arbitrary value, or at least to the number 485 of the Autonomous System from which the routes were learned. 487 Other uses of the route tag are valid, as long as all routers in the 488 IGRPng autonomous system use it consistently. 490 The maximum datagram size is limited by the MTU of the medium over 491 which the protocol is being used. Since an unsolicited IGRPng update 492 is never propagated across a router, there is no danger of an MTU 493 mismatch. The determination of the number of RTEs which may be put 494 into a given message is a function of the medium's MTU, the number of 495 octets of IPv6 header information (including options and extension 496 headers) preceding the IGRPng message, the size of the IGRPng header, 497 and the size of an RTE. The formula is: 499 +- -+ 500 | MTU - sizeof(IPv6_hdrs) - IGRPng_hdrlen | 501 #RTEs = INT | --------------------------------------- | 502 | RTE_size | 503 +- -+ 505 2.1.1 Next-Hop 507 IGRPng uses the link-local source address of an update message as the 508 next-hop address for RTEs that are installed as routes. IGRPng also 509 provides the ability to specify the immediate next-hop IPv6 address 510 to which packets to a destination specified by a route table entry 511 (RTE) should be forwarded in much the same way as RIP-2 [12]. In 512 RIP-2, each route table entry has a next-hop field. Including a 513 next-hop field for each RTE in IGRPng would nearly double the size of 514 the RTE. Therefore, in IGRPng, the next-hop is specified by a 515 special RTE and applies to all of the address RTEs following the 516 next-hop RTE until the end of the message or until another next-hop 517 RTE is encountered. 519 A next-hop RTE is identified by a value of 0xFF in the hop-count 520 field of an RTE. The prefix field specifies the IPv6 address of the 521 next hop. The prefix length, delay, bandwidth, mtu, and route tag in 522 the next-hop RTE must be set to zero on sending and ignored on 523 reception. 525 The next-hop Route Table Entry (RTE) has the following format: 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | | 531 ~ IPv6 prefix (16) ~ 532 | | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 |must be zero(1)| 0xFF | must be zero (2) | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | must be zero (4) | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | must be zero (4) | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | must be zero (2) | must be zero (2) | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Specifying a value of 0:0:0:0:0:0:0:0 in the prefix field of a next hop 544 RTE indicates that the next-hop address should be the originator of the 545 IGRPng advertisement. Other than this special address, an address 546 specified as a next-hop must be a link-local address. 548 The purpose of the next-hop RTE is to eliminate packets being routed 549 through extra hops in the system. It is particularly useful when IGRPng 550 is not being run on all of the routers on a network. Note that next-hop 551 RTE is "advisory". That is, if the provided information is ignored, a 552 possibly sub-optimal, but valid, route may be taken. If the received 553 next-hop address is not a link-local address or the special address 554 0:0:0:0:0:0:0:0 the next-hop RTE must be ignored. Processing continues 555 with the next RTE. 557 2.2 The Default Route 559 RIPng and other routing protocols propagate a default route when it is 560 not convenient to list every possible network in routing updates, and 561 when one or more routers in the system are prepared to handle traffic to 562 networks that are not explicitly listed. These "default routers" use the 563 default route as a path for all datagrams for which they have no 564 explicit route. 566 The default route for RIPng is designated by any prefix with a prefix 567 length of zero. Typically the default route is specified with the 568 prefix 0:0:0:0:0:0:0:0, though the prefix is essentially ignored. 570 Instead of supporting the propagation of this pseudo route, IGRPng has 571 the ability to mark routes as exterior. These "exterior" routes are 572 used as candidates for the default route on each router they are 573 received on. The next-hop from the exterior route with the lowest 574 composite metric is used as the next-hop for the default route on a 575 given router. Exterior routes are equivalent to interior routes with 576 the additional feature that only exterior routes are considered as 577 candidates for the default route. This approach to the default route is 578 more flexible than that of RIPng (see section 4 of [13] for an example 579 of why this is the case). When propagating an exterior route, its 580 exterior property must be preserved. 582 The mechanism on how to initially mark a network on a router as exterior 583 is left to the implementor. In general, the system administrator should 584 be provided with a way to specify which directly connected networks of a 585 router can be advertised as exterior route entries. If this mechanism 586 is used, the implementation should allow the network administrator to 587 choose the metrics associated with the exterior route advertisement in 588 the absence of full IGRPng metric information from a peer AS border 589 router. This makes it possible to establish precedence among multiple 590 default routers. 592 Each IGRPng router is configured with the AS numbers of other IGRPng 593 peers it is willing to accept routing information from. This feature 594 enables IGRPng routers to enforce routing boundaries and prevent the 595 propagation of routes outside their configured scope. This is important 596 for controlling where exterior routes are advertised. 598 2.3 Timers 600 This section describes all events that are triggered by timers. 602 Every 30 seconds, the IGRPng process is awakened to send an unsolicited 603 Update message, containing the complete routing table (see section 2.6.3 604 on Split Horizon), to every neighboring router. When there are many 605 routers on a single network, there is a tendency for them to synchronize 606 with each other such that they all issue updates at the same time. This 607 can happen whenever the 30 second timer is affected by the processing 608 load on the system. It is undesirable for the update messages to become 609 synchronized, since it can lead to unnecessary collisions on broadcast 610 networks (see [14] for more details). Therefore, implementations are 611 required to take one of two precautions: 613 - The 30-second updates are triggered by a clock whose rate is not 614 affected by system load or the time required to service the previous 615 update timer. 617 - The 30-second timer is offset by a random time (+/- 0 to 15 seconds) 618 each time it is set. The offset is derived from 0.5 * the update 619 period (i.e. 30). 621 There are two or three timers associated with each route (depending on 622 whether hold-downs are enabled), a "timeout", a "hold-down time" if 623 hold-downs are enabled, and a "garbage-collection time." Upon 624 expiration of the timeout, the route is no longer valid and must not be 625 used to forward packets. However, it is retained in the routing table 626 for a short time so that neighbors can be notified that the route has 627 been dropped. If hold-downs are enabled, then until expiration of the 628 hold-down timer no new updates for the route are accepted, even if they 629 indicate reachability. Upon expiration of the garbage-collection timer, 630 the route is finally removed from the routing table. 632 The timeout is initialized when a route is established, and any time an 633 update message is received for the route. If 90 seconds elapse from the 634 last time the timeout was initialized, the route is considered to have 635 expired, and the deletion process described below begins for that route. 637 Deletions can occur for one of two reasons: the timeout expires, or the 638 delay metric is set to 0xFFFFFFFF because of an update received from the 639 originating router of the route (see section 2.4.2 for a discussion of 640 processing updates from other routers). In either case, the following 641 events happen: 643 - The garbage-collection timer is set for 120 seconds. 645 - If hold-downs are enabled, the route lock flag is set to indicate that 646 this entry may not be updated and the hold-down timer is set for 100 647 seconds. 649 - The delay metric for the route is set to 0xFFFFFFFF (unreachable). 650 This causes the route to be removed from service. 652 - The route change flag is set to indicate that this entry has been 653 changed. 655 - The output process is signaled to send a triggered update. 657 Until the garbage-collection timer expires, the route is included in all 658 updates sent by this router. When the garbage-collection timer expires, 659 the route is deleted from the routing table. 661 When the hold-down timer expires (if hold-downs are enabled), the route 662 lock flag is cleared. 664 Should a new route to this network be established while the garbage- 665 collection timer is running, the new route will replace the one that is 666 about to be deleted only if the route lock flag is not set. If the 667 route is updated, the garbage-collection timer must be cleared. 669 Triggered updates also use a small timer; this is described in section 670 2.5.1. 672 2.3.1 Default Values 674 The timer values given in the above section are the recommended protocol 675 default values. An implementation may choose to make some or all the 676 timer values configurable. In this case the following guidelines should 677 apply: 679 - The route "timeout" value should be three times the update timer, if 680 it is not specified. 682 - The "hold-down" value should be three times the update timer plus ten, 683 if it is not specified. 685 - The "garbage-collection" value should be four times the update timer, 686 if it is not specified. 688 - The "hold-down" value must be less than the "garbage-collection" 689 value. 691 2.4 Input Processing 693 This section will describe the handling of datagrams received on the 694 IGRPng multicast group all-igrp-routers or a unicast address of the 695 router. Processing will depend upon the value in the opcode field. 696 Version 1 supports only two commands: Request and Update. 698 2.4.1 Request Messages 700 A Request is used to ask the recipient to send its routing table. There 701 is no equivalent per entry request semantics as in RIPng. Normally, 702 Requests are sent as multicasts, by routers which have just come up and 703 are seeking to fill in their routing tables as quickly as possible. A 704 router that receives a request directed at one if its globally valid 705 unicast addresses should use that unicast address as the source of the 706 response. This may occur as part of monitoring a router's routing 707 table. 709 The request message must only be an IGRPng header, otherwise the message 710 is ignored. Only the version, opcode, and autonomous system fields are 711 used. The route count fields must be zero. The checksum is checked as 712 normal. If the message is valid, a call is made to the output process 713 to send the routing table to the requesting address. The update message 714 generated by a request to a router's interface is the same as the normal 715 update message regularly sent on that interface. Normal output 716 processing is done, including Split Horizon (see section 2.6.3 on Split 717 Horizon). When a router first comes up, it multicasts a Request on 718 every connected network to get a complete routing table. It is assumed 719 that these complete routing tables are to be used to update the 720 requestor's routing table. For this reason, split horizon processing 721 must be done. 723 2.4.2 Update Messages 725 An Update can be received for one of several different reasons: 727 - response to a specific request 728 - regular update (unsolicited update) 729 - triggered update caused by a route change 731 Processing is the same no matter why the Update was generated. 733 Because processing of an Update may update the router's routing table, 734 the Update must be checked carefully for validity. The size of the 735 datagram minus any IPv6 network layer headers and the IGRPng header must 736 be a multiple of the size of an RTE. The sum of the interior and 737 exterior route counts must be the same as the actual number of RTEs in 738 the update message. If either of these conditions is not true, the 739 datagram must be discarded. The datagram's IPv6 source address should 740 be checked to see whether the datagram is from a valid neighbor and must 741 be a link-local address. It is also worth checking to see whether the 742 update is from one of the router's own addresses. Interfaces on 743 broadcast networks may receive copies of their own multicasts 744 immediately. If a router processes its own output as new input, 745 confusion is likely, and such datagrams must be ignored. As an 746 additional check, periodic advertisements must have their IPv6 header 747 hop-count set to 255, and inbound, multicast packets (i.e. periodic 748 advertisement or triggered update packets) must be examined to ensure 749 that the hop-count is 255. This guarantees that a packet is from a 750 neighbor, because any intermediate node would have decremented the hop- 751 count. Requests and their responses may still cross intermediate nodes 752 and therefore do not require the hop-count test to be done. 754 Once the datagram as a whole has been validated, process the RTEs in 755 order. Again, start by doing validation. Format errors usually 756 indicate misbehaving neighbors and should probably be brought to the 757 administrator's attention. The basic validity tests are: 759 - is the destination prefix of the RTE valid (e.g., not a multicast 760 prefix) 761 - is the prefix length of the RTE valid (i.e., between 0 and 128, 762 inclusive) 764 If any check fails, ignore that RTE and proceed to the next. The error 765 should be logged. 767 There are two types of RTEs: interior and exterior. The only difference 768 between the two is that exterior RTEs are used as candidates for the 769 default route. Otherwise processing is the same for both types of RTEs. 770 Interior and exterior RTEs have no distinguishing fields, the route 771 counts are the only indication of which type an RTE is. Interior routes 772 always proceed exterior routes. 774 If the delay metric for each received RTE indicates it is reachable, a 775 composite metric is calculated to combine the metric information (e.g. 776 delay, bandwidth, etc.) into a single measure of a path's "goodness". 777 This single composite value makes comparisons with existing routes 778 easier. The smaller the composite metric the better a path is. The 779 vector of metrics gives better accuracy in computing routes. If 780 multiple paths have the same composite metric, traffic can be split 781 among the paths. 783 Once the entry has been validated and is reachable, the individual 784 metrics must first be updated to account for the metrics of the incoming 785 interface. Only after the metrics are updated is the composite metric 786 calculated. The metrics are updated as follows: 788 - delay = delay from the message + receiving interface delay 789 - bandwidth = MAX (bandwidth from the message, receiving interface 790 bandwidth) 791 - MTU = MIN (MTU from the message, receiving interface MTU) 792 - hop-count = MIN (hop-count from the message + 1, maximum hop-count) 794 If the MTU is set to zero, the MTU of the receiving interface is used. 796 Next, the composite metric is calculated according to the following 797 calculation: 799 - composite metric = K1 * bandwidth + K2 * delay 801 where: 803 K1 and K2 are weighted constants configurable in a manner not specified 804 by this document. By default, K1 and K2 should be set to one. 806 Now, check to see whether there is already an explicit route for the 807 destination prefix. If there is no such route, add this route to the 808 routing table, unless the delay metric is unreachable (there is no point 809 in adding a route which unusable). If there is a route and it is in a 810 locked hold-down state, the RTE is ignored. Adding a route to the 811 routing table consists of: 813 - Setting the destination prefix and length to those in the RTE. 815 - Setting the metrics to the newly calculated metrics (as described 816 above). 818 - Set the next-hop address to be the address of the router from which 819 the datagram came or the next-hop address specified by a next-hop RTE. 821 - Initialize the timeout for the route. If the garbage-collection timer 822 is running for this route, stop it (see section 2.3 for a discussion 823 of the timers). 825 - Set the route change flag. 827 - Signal the output process to trigger an update (see section 2.5). 829 If there is an existing route that is not in a locked hold-down, compare 830 the originator of the route to the address of the router from which the 831 datagram was originated. If this datagram is from the same router as 832 the existing route; do the following actions: 834 - If the new delay metric is unreachable, the deletion process begins 835 for the route, which is no longer used for routing packets. Note that 836 the deletion process is started only when the delay metric is first 837 set to unreachable. If the metric was already infinity, then a new 838 deletion process is not started. 840 - If hold-downs are enabled and the composite metric has increased by 841 more than 10%, the deletion process begins for the route, which is no 842 longer used for routing packets. 844 - If hold-downs are disabled and the hop-count has increased and the 845 composite metric has increased, the deletion process begins for the 846 route, which is no longer used for routing packets. 848 - Otherwise, reinitialize the timeout. If the metrics are different put 849 the new metrics in, and adjust the next-hop address (if necessary). 851 - Set the route change flag and signal the output process to send a 852 triggered update. 854 In the above, if hold-downs are enabled the deletion process includes 855 marking the route as in the locked hold-down state. 857 If the datagram is not from the originating router and the new composite 858 metric is lower than the old one; do the following actions: 860 - Adopt the route from the datagram and reinitialize the timeout. That 861 is, put the new metrics in, and adjust the next-hop address (if 862 necessary). 864 - Set the route change flag and signal the output process to send a 865 triggered update. 867 If the new composite metric is the same as the old one, it is simplest 868 to do nothing further; but, there is a heuristic which could be applied. 869 Normally, it is senseless to replace a route if the new route has the 870 same composite metric as the existing route; this would cause the route 871 to bounce back and forth, which would generate an intolerable number of 872 triggered updates. However, if the existing route is showing signs of 873 timing out, it may be better to switch to an alternative route 874 immediately, rather than waiting for the timeout to happen. Therefore, 875 if the new composite metric is the same as the old one, examine the 876 timeout for the existing route. If it is at least two-thirds to the 877 expiration point, switch to the new route. This heuristic is optional, 878 but highly recommended. 880 Any entry that fails these tests is ignored, as it is no better than the 881 current route. 883 2.5 Output Processing 885 This section describes the processing used to create update messages 886 that contain all or part of the routing table. This processing may be 887 triggered in any of the following ways: 889 - By input processing, when a Request is received. In this case, the 890 Update is sent to only one destination (i.e. the unicast address of 891 the requestor). 893 - By the regular routing update. Every 30 seconds, an Update containing 894 the whole routing table is sent to every neighboring router. 896 - By triggered updates. Whenever the metrics for a route are changed, 897 an update is triggered. 899 The processing required for a Request is described in section 2.4.1. 901 When an Update is to be sent to all neighbors (i.e., a regular or 902 triggered update), an Update message is multicast to the all-igrp- 903 routers multicast group, on all connected networks that support 904 broadcasting or are point-to-point links. IGRPng handles point-to-point 905 links the same as multi-access links, as multicasting is trivially 906 provided on such links. Thus, one Update is prepared for each directly- 907 connected network, and sent to the all-igrp-routers multicast group. In 908 most cases, this reaches all neighboring routers. However, there are 909 some cases where this may not be enough. This may involve a network that 910 is not a broadcast network (e.g., the ARPANET), or a situation involving 911 dumb routers. In such cases, it may be necessary to specify an actual 912 list of neighboring routers and send a datagram to each one explicitly. 913 It is left to the implementor to determine whether such a mechanism is 914 needed, and to define how the list is specified. 916 2.5.1 Triggered Updates 918 Triggered updates require special handling for two reasons. First, 919 experience shows that triggered updates can cause excessive loads on 920 networks with limited capacity or networks with many routers on them. 921 Therefore, the protocol requires that implementors include provisions to 922 limit the frequency of triggered updates. After a triggered update is 923 sent, a timer should be set for a random interval between 1 and 5 924 seconds. If other changes that would trigger updates occur before the 925 timer expires, a single update is triggered when the timer expires. The 926 timer is then reset to another random value between 1 and 5 seconds. 927 Triggered updates should be suppressed if a regular update is due by the 928 time the triggered update would be sent. 930 Second, triggered updates do not need to include the entire routing 931 table. In principle, only those routes which have changed need to be 932 included. Therefore messages generated as part of a triggered update 933 must include at least those routes that have their route change flag 934 set. They may include additional routes, at the discretion of the 935 implementor; however, sending complete routing updates is strongly 936 discouraged. When a triggered update is processed, messages should be 937 generated for every directly-connected network. Split Horizon 938 processing is done when generating triggered updates as well as normal 939 updates (see section 2.6.3). If, after Split Horizon processing for a 940 given network, a changed route will appear unchanged on that network the 941 route need not be sent. If no routes need be sent on that network, the 942 update may be omitted. Once all of the triggered updates have been 943 generated, the route change flags should be cleared. 945 If input processing is allowed while output is being generated, 946 appropriate interlocking must be done. The route change flags should 947 not be changed as a result of processing input while a triggered update 948 message is being generated. 950 The only difference between a triggered update and other update messages 951 is the possible omission of routes that have not changed. The remaining 952 mechanisms, described in the next section, must be applied to all 953 updates. 955 2.5.2 Generating Update Messages 957 This section describes how an Update message is generated for a 958 particular directly-connected network: 960 The IPv6 source address must be one of the link-local addresses of the 961 sending router's interface, except when replying to a unicast Request 962 Message from a non-local source address. In the latter case, the source 963 address must be the globally valid address the request was directed to. 964 In the former case, it is important to use a link-local address because 965 the source address is put into routing tables (as the next-hop) in the 966 routers which receive this Update. If an incorrect source address is 967 used, other routers may be unable to route datagrams. The IPv6 hop- 968 count must be set to 255 to ensure routers can determine if the message 969 has been forwarded. It is possible that a router may have multiple 970 link-local addresses for a single interface. In this case, the router 971 must only originate a single Update message with a source address of the 972 designated link-local address for a given interface. The choice of 973 which link-local address to use should only change when the current 974 choice is no longer valid. This is necessary because nodes receiving 975 Update messages use the source address to identify the sender. If 976 multiple packets from the same router contain different source 977 addresses, nodes will assume they come from different routers, leading 978 to undesirable behavior. 980 Set the version number to the current version of IGRPng. The version 981 described in this document is version 1. Set the opcode to Update. Set 982 the autonomous system to the configured number. Set the address family 983 identifier to 2. Set the bytes labeled "must be zero" to zero. Start 984 filling in RTEs, keeping count of the number of interior and exterior 985 routes that are included. Recall that the maximum datagram size is 986 limited by the network's MTU. When there is no more space in the 987 datagram, set the interior and exterior route counts appropriately, 988 compute the checksum over the entire IGRPng message, send the current 989 Update and start a new one. Repeat the process until all routes have 990 been sent. 992 To fill in the RTEs, examine each route in the routing table. If a 993 triggered update is being generated, only entries whose route change 994 flags are set need be included. If, after Split Horizon processing, the 995 route should not be included, skip it. If the route is to be included, 996 then the destination prefix, prefix length, and metrics are put into the 997 RTE. The route tag is filled in as defined in section 2.1. Routes must 998 be included in the datagram even if their metrics indicate the route is 999 unreachable. 1001 2.6 Stability Features 1003 IGRPng cannot rely on the same mechanism as RIPng for removing routing 1004 loops (i.e. "counting to infinity"). This is due to the fact that the 1005 range of metric values allowed in IGRPng is much larger. Because of 1006 this, IGRPng must be aggressive in assuring that routing loops never 1007 form. It does this by potentially ignoring valid routing information for 1008 some period of time. 1010 IGRPng uses a combination of four techniques to prevent routing loops 1011 from forming: route hold-downs, triggered updates, split horizon, and 1012 route poisoning. The exact technique used depends on whether hold-downs 1013 are enabled or not. Because networks can lose updates or have them 1014 delayed, it is possible that invalid routing information can exist in 1015 the network for some period of time. Therefore, there is some 1016 redundancy in the measures to ensure invalid routing information is 1017 never accepted as valid. 1019 2.6.1 Route Hold-downs 1021 Hold-downs in IGRPng are designed to prevent routing update information 1022 from being accepted for a route for some period of time after the route 1023 is marked unreachable. This is to ensure that the update is not an echo 1024 of the route that continues to exist in the network. The hold-down 1025 period needs to be long enough for triggered updates to propagate 1026 throughout the IGRPng autonomous system plus a couple of update cycles 1027 to account for dropped updates. If a triggered update is lost, the next 1028 regular update cycle will restart the triggered update wave. 1030 Routes can become unreachable for a number of reasons: 1032 - The originator of the route marks the route as unreachable in a 1033 received update packet. 1035 - The route "timeout" timer expires. 1037 - If hold-downs are enabled and the composite metric information from 1038 the originator of the route has increased by more than 10%. 1040 - If hold-downs are disabled, the composite metric has increased, and 1041 the hop-count has increased. Obviously, the route is not placed in 1042 hold-down in this case. 1044 2.6.2 Triggered Updates 1046 Normal updates periodically send a router's complete routing state. 1047 Triggered updates are used to send updates that contain information that 1048 has recently changed (i.e. when a route is unreachable). Triggered 1049 updates are designed to speed the convergence of the routing in an 1050 IGRPng autonomous system (see section 2.5.1 for more information). The 1051 problem with triggered updates is that packets may be dropped, corrupted 1052 or delayed potentially delaying the convergence of the topology. 1054 2.6.3 Split Horizon 1056 Split Horizon is a algorithm for avoiding problems caused by including 1057 routes in updates sent to the router from which they were learned. This 1058 helps avoid routing loops on a small scale (i.e. between two adjacent 1059 routers on a network). It also helps to keep the size of update 1060 messages to a minimum. The basic split horizon algorithm omits routes 1061 learned from one neighbor in updates sent to that neighbor. In the case 1062 of a broadcast network, all routes learned from any neighbor on that 1063 network are omitted from updates sent on that network. 1065 Split Horizon with Poisoned Reverse (more simply, Poison Reverse) does 1066 include such routes in updates, but sets their metrics to unreachable. 1067 This is the preferred method of operation; however, implementations 1068 should provide per-interface control allowing no horizoning, split 1069 horizoning, or poisoned reverse to be selected. 1071 For a theoretical discussion of Split Horizon and Poison Reverse and why 1072 they are needed, see section 2.1.1 of [5] and section 5.2 of [13]. 1074 2.6.4 Route Poisoning 1076 While split horizon avoids routing loops at a small scale, route 1077 poisoning is designed to avoid loops at a large scale. The basic idea 1078 is that if a route's metrics increase sufficiently, the route should be 1079 marked unreachable and placed in a hold-down state. In the hold-down 1080 state any updates for this route are ignored. When hold-downs are 1081 enabled, route poisoning can delay the adoption of new routes when an 1082 old one fails. Route poisoning has different behavior depending on if 1083 hold-downs are enabled. 1085 - If hold-downs are enabled and the composite metric information from 1086 the originator of the route has increased by more than 10%. 1088 - If hold-downs are disabled, the composite metric has increased, and 1089 the hop-count has increased. Obviously, the route is not placed in 1090 hold-down in this case. 1092 Note, it is possible that the update is valid, but there is no way to 1093 distinguish this case from an echo of an old update. Therefore, a 1094 conversative approach must be taken and the route is marked unreachable. 1095 If valid information for a route exists, it will be utilized during a 1096 later update. 1098 3. Control Functions 1100 This section describes administrative controls. These are not part of 1101 the protocol per se; however, experience with existing networks suggests 1102 that they are important. 1104 3.1 Required Control Functions 1106 It is required that implementations have the ability to configure 1107 whether hold-downs are enabled or disabled. The setting of the hold- 1108 down state influences some protocol actions and all IGRPng routers in an 1109 AS must be configured with the same hold-down behavior. Otherwise, 1110 unpredictable routing may occur. By default hold-downs should be 1111 enabled. 1113 3.2 Optional Control Functions 1115 Because the reset of the control functions are not a necessary part of 1116 the protocol, they are considered optional. However, it is strongly 1117 recommend that at least some of them be included in every 1118 implementation. These controls are intended primarily to allow IGRPng 1119 to be connected to networks whose routing may be unstable or subject to 1120 errors. Here are some examples: 1122 - It is sometimes desirable to restrict the routers from which updates 1123 will be accepted, or to which updates will be sent. This is usually 1124 done for administrative, routing policy reasons. 1126 - A number of sites limit the set of networks that they allow in Update 1127 messages. Organization A may have a connection to organization B that 1128 they use for direct communication. For security or performance 1129 reasons A may not be willing to give other organizations access to 1130 that connection. In such a case, A should not include B's networks in 1131 updates that A sends to third parties. 1133 Here are some typical controls. Note, however, that the IGRPng protocol 1134 does not require these or any other controls. 1136 - A neighbor list which allows the network administrator to be able to 1137 define a list of neighbors for each router. A router would accept 1138 update messages only from routers on its list of neighbors. A similar 1139 list for target routers should also be available to the administrator. 1140 By default, no restrictions are defined. 1142 - A filter for specific destinations would permit the network 1143 administrator to be able to specify a list of destination prefixes to 1144 allow or disallow. The list would be associated with a particular 1145 interface in the incoming and/or outgoing directions. Only allowed 1146 networks would be mentioned in Update messages going out or processed 1147 in Update messages coming in. If a list of allowed prefixes is 1148 specified, all other prefixes are disallowed. If a list of disallowed 1149 prefixes is specified, all other prefixes are allowed. By default, no 1150 filters are applied. 1152 - The ability to configure different values for the protocol timers (see 1153 section 2.3.1 for details). 1155 - The ability to configure the delay, bandwidth, and mtu metrics for 1156 each directly connected network. 1158 - As mention in section 2.6.3 it may be desirable to set the split 1159 horizon mode per interface. The three settings are: no horizoning, 1160 split horizoning, or poisoned reverse. By the default the setting 1161 should be split horizoning. 1163 4. Issues 1165 This section describes issues that have not yet been resolved: 1167 - IGRP has a feature known as "specific split-horizon". This occurs 1168 when a request is made and in replying the router only omits routes 1169 that use the requestor as the next-hop. It is debatable if this 1170 feature is desirable in IGRP, however since IGRPng has the ability to 1171 include a next-hop address other than itself for a route, routers can 1172 provide the correct next-hop to the requestor. 1174 - It may be desirable to change the units of the delay field to provide 1175 for shorter delays (e.g. 100ns). It is for further study if the unit 1176 of the delay field would require the unit of the bandwidth field to 1177 change by the same order of magnitude. 1179 - IGRPng has a checksum for the contents of the IGRPng packet, this does 1180 not protect the IPv6 header. A pseudo checksum for the IPv6 header 1181 may need to be done. 1183 - The support for multiple equal-cost paths needs to be written. 1185 - Is there a minimum MTU to better define the range of acceptable values 1186 for the field? 1188 - If hold-downs are disabled is there a possibility of a routing loop 1189 with some timer settings? If so, should a maximum hop-count value be 1190 defined for the protocol to stop the propagation of the RTEs in 1191 question? 1193 5. Security Considerations 1195 Since IGRPng runs over IPv6, IGRPng relies on the IP Authentication 1196 Header (see [15]) and the IP Encapsulating Security Payload (see [16]) 1197 to ensure integrity and authentication/confidentiality of routing 1198 exchanges. 1200 References 1202 [1] Malkin, G., and Minnear, R., "RIPng", 1203 draft-ietf-rip-ripng-04.txt, August 1996 1205 [2] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks", 1206 Princeton University Press, Princeton, N.J., 1962. 1208 [3] Bellman, R. E., "Dynamic Programming", Princeton University Press, 1209 Princeton, N.J., 1957. 1211 [4] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice- 1212 Hall, Englewood Cliffs, N.J., 1987. 1214 [5] Hedrick, C., "Routing Information Protocol", Request For Comments 1215 (RFC) 1058, Rutgers University, June 1988. 1217 [6] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M., "Pup: 1218 An Internetwork Architecture", IEEE Transactions on Communications, 1219 April 1980. 1221 [7] Xerox Corp., "Internet Transport Protocols", Xerox System 1222 Integration Standard XSIS 028112, December 1981. 1224 [8] Mills, D., "DCN Local-Network Protocols", Request For Comments (RFC) 1225 891, December 1983. 1227 [9] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 1228 Specification", Request For Comments (RFC) 1883, January 1996. 1230 [10] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery for IP 1231 Version 6 (IPv6)", draft-ietf-ipngwg-discovery-06.txt, March 1996. 1233 [11] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", Request For Comments 1234 (RFC) 1700, October 1994. 1236 [12] Malkin, G., "RIP Version 2 - Carrying Additional Information", 1237 Request For Comments (RFC) 1723, Xylogics, Inc., November, 1994. 1239 [13] Hedrick, C., "An Introduction to IGRP", Center for Computers and 1240 Information Services, Rutgers University, August 1991. 1242 [14] Floyd, S., and Jacobson, V., "The Synchronization of Periodic 1243 Routing Messages", Proceedings of ACM SIGCOMM '93, September 1993. 1245 [15] Atkinson, R., "IP Authentication Header", Request For Comment (RFC) 1246 1826, Naval Research Laboratory, August 1995. 1248 [16] Atkinson, R., "IP Encapsulating Security Payload (ESP)", Request 1249 For Comment (RFC) 1827, Naval Research Laboratory, August 1995. 1251 Authors' Addresses 1253 Robert E. Minnear 1254 Ipsilon Networks, Inc. 1255 232 Java Drive 1256 Sunnyvale, CA 94089 1258 Phone: (408) 990-2014 1259 EMail: minnear@ipsilon.com 1261 Robert M. Hinden 1262 Ipsilon Networks, Inc. 1263 232 Java Drive 1264 Sunnyvale, CA 94089 1266 Phone: (408) 990-2004 1267 EMail: hinden@ipsilon.com