idnits 2.17.1 draft-ietf-rip-ripng-02.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-25) 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 ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance 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 (February 1996) is 10297 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) ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '1') ** Obsolete normative reference: RFC 1723 (ref. '2') (Obsoleted by RFC 2453) -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1009 (ref. '6') (Obsoleted by RFC 1812) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-discovery-04 Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft-ietf-rip-ripng-02.txt G. Malkin/Xylogics 3 February 1996 5 RIPng for IPv6 7 Abstract 9 This document specifies a routing protocol for an IPv6 internet. It 10 is based on protocols and algorithms currently in wide use in the 11 IPv4 Internet. 13 This specification represents the minimum change to the Routing 14 Information Protocol (RIP), as specified in RFC 1058 [1] and RFC 1723 15 [2], necessary for operation over IPv6 [3]. 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 To learn the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ds.internic.net (US East Coast), nic.nordu.net 32 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 33 Rim). 35 Acknowledgements 37 This document is a modified version of RFC 1058, written by Chuck 38 Hendrick [1]. The modifications reflect RIP-2 and IPv6 enhancements, 39 but the original wording is his. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 1.1 Theoretical Underpinnings . . . . . . . . . . . . . . . . . 4 45 1.2 Limitations of the Protocol . . . . . . . . . . . . . . . . 4 46 2. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4 47 2.1 Message Format . . . . . . . . . . . . . . . . . . . . . . . 6 48 2.2 Addressing Considerations . . . . . . . . . . . . . . . . . 7 49 2.3 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 50 2.4 Input Processing . . . . . . . . . . . . . . . . . . . . . . 9 51 2.4.1 Request Messages . . . . . . . . . . . . . . . . . . . . . 9 52 2.4.2 Response Messages . . . . . . . . . . . . . . . . . . . . 10 53 2.5 Output Processing . . . . . . . . . . . . . . . . . . . . . 13 54 2.5.1 Triggered Updates . . . . . . . . . . . . . . . . . . . . 13 55 2.5.2 Generating Response Messages . . . . . . . . . . . . . . . 14 56 2.6 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 15 57 3. Control Functions . . . . . . . . . . . . . . . . . . . . . . 15 58 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 16 59 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 62 1. Introduction 64 This memo describes one protocol in a series of routing protocols 65 based on the Bellman-Ford (or distance vector) algorithm. This 66 algorithm has been used for routing computations in computer networks 67 since the early days of the ARPANET. The particular packet formats 68 and protocol described here are based on the program "routed," which 69 is included with the Berkeley distribution of Unix. 71 In an international network, such as the Internet, it is very 72 unlikely that a single routing protocol will used for the entire 73 network. Rather, the network will be organized as a collection of 74 Autonomous Systems (AS), each of which will, in general, be 75 administered by a single entity. Each AS will have its own routing 76 technology, which may differ among AS's. The routing protocol used 77 within an AS is referred to as an Interior Gateway Protocol (IGP). A 78 separate protocol, called an Exterior Gateway Protocol (EGP), is used 79 to transfer routing information among the AS's. RIPng was designed 80 to work as an IGP in moderate-size AS's. It is not intended for use 81 in more complex environments. For information on the context into 82 which RIP version 1 (RIP-1) is expected to fit, see Braden and Postel 83 [6]. 85 RIPng is one of a class of algorithms known as Distance Vector 86 algorithms. The earliest description of this class of algorithms 87 known to the author is in Ford and Fulkerson [8]. Because of this, 88 they are sometimes known as Ford-Fulkerson algorithms. The term 89 Bellman-Ford is also used, and derives from the fact that the 90 formulation is based on Bellman's equation [4]. The presentation in 91 this document is closely based on [5]. This document contains a 92 protocol specification. For an introduction to the mathematics of 93 routing algorithms, see [1]. The basic algorithms used by this 94 protocol were used in computer routing as early as 1969 in the 95 ARPANET. However, the specific ancestry of this protocol is within 96 the Xerox network protocols. The PUP protocols [7] used the Gateway 97 Information Protocol to exchange routing information. A somewhat 98 updated version of this protocol was adopted for the Xerox Network 99 Systems (XNS) architecture, with the name Routing Information 100 Protocol [9]. Berkeley's routed is largely the same as the Routing 101 Information Protocol, with XNS addresses replaced by a more general 102 address format capable of handling IPv4 and other types of address, 103 and with routing updates limited to one every 30 seconds. Because of 104 this similarity, the term Routing Information Protocol (or just RIP) 105 is used to refer to both the XNS protocol and the protocol used by 106 routed. 108 1.1 Theoretical Underpinnings 110 An introduction to the theory and math behind Distance Vector 111 protocols is provided in [1]. It has not been incorporated in this 112 document for the sake of brevity. 114 1.2 Limitations of the Protocol 116 This protocol does not solve every possible routing problem. As 117 mentioned above, it is primary intended for use as an IGP in networks 118 of moderate size. In addition, the following specific limitations 119 are be mentioned: 121 - The protocol is limited to networks whose longest path (the 122 network's diameter) is 15 hops. The designers believe that the 123 basic protocol design is inappropriate for larger networks. Note 124 that this statement of the limit assumes that a cost of 1 is used 125 for each network. This is the way RIPng is normally configured. 126 If the system administrator chooses to use larger costs, the upper 127 bound of 15 can easily become a problem. 129 - The protocol depends upon "counting to infinity" to resolve certain 130 unusual situations (see section 2.2 in [1]). If the system of 131 networks has several hundred networks, and a routing loop was 132 formed involving all of them, the resolution of the loop would 133 require either much time (if the frequency of routing updates were 134 limited) or bandwidth (if updates were sent whenever changes were 135 detected). Such a loop would consume a large amount of network 136 bandwidth before the loop was corrected. We believe that in 137 realistic cases, this will not be a problem except on slow lines. 138 Even then, the problem will be fairly unusual, since various 139 precautions are taken that should prevent these problems in most 140 cases. 142 - This protocol uses fixed "metrics" to compare alternative routes. 143 It is not appropriate for situations where routes need to be chosen 144 based on real-time parameters such a measured delay, reliability, 145 or load. The obvious extensions to allow metrics of this type are 146 likely to introduce instabilities of a sort that the protocol is 147 not designed to handle. 149 2. Protocol Specification 151 RIPng is intended to allow routers to exchange information for 152 computing routes through an IPv6-based network. RIPng is a distance 153 vector protocol, as described in [1]. RIPng should be implemented 154 only in routers; IPv6 provides other mechanisms for router discovery 156 [10]. Any router that uses RIP is assumed to have interfaces to one 157 or more networks, otherwise it isn't really a router. These are 158 referred to as its directly-connected networks. The protocol relies 159 on access to certain information about each of these networks, the 160 most important of which is its metric. The RIPng metric of a network 161 is an integer between 1 and 15, inclusive. It is set in some manner 162 not specified in this protocol; however, given the maximum path limit 163 of 15, a value of 1 is usually used. Implementations should allow 164 the system administrator to set the metric of each network. In 165 addition to the metric, each network will have an IPv6 destination 166 address prefix and prefix length associated with it. These are to be 167 set by the system administrator in a manner not specified in this 168 protocol. 170 Each router that implements RIPng is assumed to have a routing table. 171 This table has one entry for every destination that is reachable 172 throughout the system operating RIPng. Each entry contains at least 173 the following information: 175 - The IPv6 prefix of the destination. 177 - A metric, which represents the total cost of getting a datagram 178 from the router to that destination. This metric is the sum of the 179 costs associated with the networks that would be traversed to get 180 to the destination. 182 - The IPv6 address of the next router along the path to the 183 destination (i.e., the next hop). If the destination is on one of 184 the directly-connected networks, this item is not needed. 186 - A flag to indicate that information about the route has changed 187 recently. This will be referred to as the "route change flag." 189 - Various timers associated with the route. See section 2.3 for more 190 details on timers. 192 The entries for the directly-connected networks are set up by the 193 router using information gathered by means not specified in this 194 protocol. The metric for a directly-connected network is set to the 195 cost of that network. As mentioned, 1 is the usual cost. In that 196 case, the RIP metric reduces to a simple hop-count. More complex 197 metrics may be used when it is desirable to show preference for some 198 networks over others (e.g., to indicate of differences in bandwidth 199 or reliability). 201 Implementors may also choose to allow the system administrator to 202 enter additional routes. These would most likely be routes to hosts 203 or networks outside the scope of the routing system. They are 204 referred to as "static routes." Entries for destinations other than 205 these initial ones are added and updated by the algorithms described 206 in the following sections. 208 In order for the protocol to provide complete information on routing, 209 every router in the AS must participate in the protocol. In cases 210 where multiple IGPs are in use, there must be at least one router 211 which can leak routing information between the protocols. 213 2.1 Message Format 215 RIPng is a UDP-based protocol. Each router that uses RIPng has a 216 routing process that sends and receives datagrams on UDP port number 217 , the RIPng port. All communications intended for another 218 routers's RIPng process are sent to the RIPng port. All routing 219 update messages are sent from the RIPng port. Unsolicited routing 220 update messages have both the source and destination port equal to 221 the RIPng port. Those sent in response to a request are sent to the 222 port from which the request came. Specific queries may be sent from 223 ports other than the RIPng port, but they must be directed to the 224 RIPng port on the target machine. 226 The RIPng packet format is: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | command (1) | version (1) | must be zero (2) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | | 234 ~ IPv6 prefix (16) ~ 235 | | 236 +---------------------------------------------------------------+ 237 | must be zero (2) | prefix len (1)| metric (1) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 The 20-octet portion of the datagram from IPv6 prefix through 241 metric, the Routing Entry (RTE), may appear one or more times. 242 The maximum number of RTEs is defined below. 244 Field sizes are given in octets. Unless otherwise specified, fields 245 contain binary integers, in network byte order, with the most- 246 significant octet first (big-endian). Each tick mark represents one 247 bit. 249 Every message contains a RIPng header which consists of a command and 250 a version number. This document describes version 1 of the protocol 251 (see section 2.4). The command field is used to specify the purpose 252 of this message. The commands implemented in version 1 are: 254 1 - request A request for the responding system to send all or 255 part of its routing table. 257 2 - response A message containing all or part of the sender's 258 routing table. This message may be sent in response 259 to a request, or it may be an unsolicited routing 260 update generated by the sender. 262 For each of these message types, the remainder of the datagram 263 contains a list of RTEs. Each RTE in this list contains a 264 destination prefix, the number of significant bits in the prefix, and 265 the cost to reach that destination (metric). 267 The destination prefix is the usual 128-bit, IPv6 address prefix 268 stored as 16 octets in network byte order. 270 The prefix length field is the number of 1-bits, starting from the 271 left, in the prefix. 273 The metric field contains a value between 1 and 15 inclusive, 274 specifying the current metric for the destination; or the value 16 275 (infinity), which indicates that the destination is not reachable. 277 The maximum datagram size is limited by the MTU of the medium over 278 which the protocol is being used. Since an unsolicited RIPng update 279 is never propagated across a router, there is no danger of an MTU 280 mismatch. The determination of the number of RTEs which may be put 281 into a given message is a function of the medium's MTU, the number of 282 octets of header information preceeding the RIPng message, the size 283 of the RIPng header, and the size of an RTE. The formula is: 285 +- -+ 286 | MTU - sizeof(IPv6_hdrs) - UDP_hdrlen - RIPng_hdrlen | 287 #RTEs = INT | --------------------------------------------------- | 288 | RTE_size | 289 +- -+ 291 2.2 Addressing Considerations 293 The distinction between network, subnet and host routes does not need 294 to be made for RIPng because an IPv6 address prefix is unambiguous. 296 The special address 0:0:0:0:0:0:0:0 (the prefix length is also zero) 297 is used to designate a default route. A default route is used when 298 it is not convenient to list every possible network in the RIPng 299 updates, and when one or more routers in the system are prepared to 300 handle traffic to the networks that are not explicitly listed. These 301 "default routers" use the default route as a path for all datagrams 302 for which they have no explicit route. The decision as to how a 303 router becomes a default router (i.e., how a default route entry is 304 created) is left to the implementor. In general, the system 305 administrator will be provided with a way to specify which routers 306 should create and advertise default route entries. If this mechanism 307 is used, the implementation should allow the network administrator to 308 choose the metric associated with the default route advertisement. 309 This will make it possible to establish a precedence amoung multiple 310 default routers. The default route entries are handled by RIPng in 311 exactly the same manner as any other destination prefix. System 312 administrators should take care to make sure that default routes do 313 not propagate further than is intended. Generally, each AS has its 314 own preferred default router. Therefore, default routes should 315 generally not leave the boundary of an AS. The mechanisms for 316 enforcing this restriction are not specified in this document. 318 2.3 Timers 320 This section describes all events that are triggered by timers. 322 Every 30 seconds, the RIPng process is awakened to send an 323 unsolicited Response message, containing the complete routing table 324 (see section 2.6 on Split Horizon), to every neighboring router. 325 When there are many routers on a single network, there is a tendency 326 for them to synchronize with each other such that they all issue 327 updates at the same time. This can happen whenever the 30 second 328 timer is affected by the processing load on the system. It is 329 undesirable for the update messages to become synchronized, since it 330 can lead to unnecessary collisions on broadcast networks. Therefore, 331 implementations are required to take one of two precautions: 333 - The 30-second updates are triggered by a clock whose rate is not 334 affected by system load or the time required to service the 335 previous update timer. 337 - The 30-second timer is offset by a small random time (+/- 0 to 5 338 seconds) each time it is set. 340 There are two timers associated with each route, a "timeout" and a 341 "garbage-collection time." Upon expiration of the timeout, the route 342 is no longer valid; however, it is retained in the routing table for 343 a short time so that neighbors can be notified that the route has 344 been dropped. Upon expiration of the garbage-collection timer, the 345 route is finally removed from the routing table. 347 The timeout is initialized when a route is established, and any time 348 an update message is received for the route. If 180 seconds elapse 349 from the last time the timeout was initialized, the route is 350 considered to have expired, and the deletion process described below 351 begins for that route. 353 Deletions can occur for one of two reasons: the timeout expires, or 354 the metric is set to 16 because of an update received from the 355 current router (see section 2.4.2 for a discussion of processing 356 updates from other routers). In either case, the following events 357 happen: 359 - The garbage-collection timer is set for 120 seconds. 361 - The metric for the route is set to 16 (infinity). This causes the 362 route to be removed from service. 364 - The route change flag is to indicate that this entry has been 365 changed. 367 - The output process is signalled to trigger a response. 369 Until the garbage-collection timer expires, the route is included in 370 all updates sent by this router. When the garbage-collection timer 371 expires, the route is deleted from the routing table. 373 Should a new route to this network be established while the garbage- 374 collection timer is running, the new route will replace the one that 375 is about to be deleted. In this case the garbage-collection timer 376 must be cleared. 378 Triggered updates also use a small timer; however, this is best 379 described in section 2.5.1. 381 2.4 Input Processing 383 This section will describe the handling of datagrams received on the 384 RIPng port. Processing will depend upon the value in the command 385 field. Version 1 supports only two commands: Request and Response. 387 2.4.1 Request Messages 389 A Request is used to ask for a response containing all or part of a 390 routers's routing table. Normally, Requests are sent as multicasts, 391 from the RIPng port, by routers which have just come up and are 392 seeking to fill in their routing tables as quickly as possible. 393 However, there may be situations (e.g., router monitoring) where the 394 routing table of only a single router is needed. In this case, the 395 Request should be sent directly to that router from a UDP port other 396 than the RIPng port. If such a Request is received, the router 397 responds directly to the requestor's address and port. 399 The Request is processed entry by entry. If there are no entries, no 400 response is given. There is one special case. If there is exactly 401 one entry in the request, and it has a destination prefix of zero and 402 a metric of infinity (i.e., 16), then this is a request to send the 403 entire routing table. In that case, a call is made to the output 404 process to send the routing table to the requesting address/port. 405 Except for this special case, processing is quite simple. Examine 406 the list of RTEs in the Request one by one. For each entry, look up 407 the destination in the router's routing database and, if there is a 408 route, put that route's metric in the metric field of the RTE. If 409 there is no explicit route to the specified destination, put infinity 410 in the metric field. Once all the entries have been filled in, 411 change the command from Request to Response and send the datagram 412 back to the requestor. 414 Note that there is a difference in metric handling for specific and 415 whole-table requests. If the request is for a complete routing 416 table, normal output processing is done, including Split Horizon (see 417 section 2.6 on Split Horizon). If the request is for specific 418 entries, they are looked up in the routing table and the information 419 is returned as is; no Split Horizon processing is done. The reason 420 for this distinction is the expectation that these requests are 421 likely to be used for different purposes. When a router first comes 422 up, it multicasts a Request on every connected network asking for a 423 complete routing table. It is assumed that these complete routing 424 tables are to be used to update the requestor's routing table. For 425 this reason, Split Horizon must be done. It is further assumed that 426 a Request for specific networks is made only by diagnostic software, 427 and is not used for routing. In this case, the requester would want 428 to know the exact contents of the routing table and would not want 429 any information hidden or modified. 431 2.4.2 Response Messages 433 A Response can be received for one of several different reasons: 435 - response to a specific query 436 - regular update (unsolicited response) 437 - triggered update caused by a route change 439 Processing is the same no matter why the Response was generated. 441 Because processing of a Response may update the router's routing 442 table, the Response must be checked carefully for validity. The 443 Response must be ignored if it is not from the RIPng port. The 444 datagram's IPv6 source address should be checked to see whether the 445 datagram is from a valid neighbor; the source of the datagram must be 446 on a directly-connected network. It is also worth checking to see 447 whether the response is from one of the router's own addresses. 448 Interfaces on broadcast networks may receive copies of their own 449 multicasts immediately. If a router processes its own output as new 450 input, confusion is likely, and such datagrams must be ignored. As 451 an additional check, periodic advertisements must have their hop 452 counts set to 255, and inbound, non-unicast packets must be examined 453 to ensure that the hop count is 255. This absolutely guarantees that 454 a packet is from a neighbor, because any intermediate node would have 455 decremented the hop count. Queries and their responses may still 456 cross intermediate nodes. 458 Once the datagram as a whole has been validated, process the RTEs in 459 the Response one by one. Again, start by doing validation. 460 Incorrect metrics and other format errors usually indicate 461 misbehaving neighbors and should probably be brought to the 462 administrator's attention. For example, if the metric is greater 463 than infinity, ignore the entry but log the event. The basic 464 validation tests are: 466 - is the destination prefix valid (e.g., not a multicast prefix) 467 - is the prefix length valid 468 - is the metric valid (i.e., between 1 and 16, inclusive) 470 If any check fails, ignore that entry and proceed to the next. 471 Again, logging the error is probably a good idea. 473 Once the entry has been validated, update the metric by adding the 474 cost of the network on which the message arrived. If the result is 475 greater than infinity, use infinity. That is, 477 metric = MIN (metric + cost, infinity) 479 Now, check to see whether there is already an explicit route for the 480 destination prefix. If there is no such route, add this route to the 481 routing table, unless the metric is infinity (there is no point in 482 adding a route which unusable). Adding a route to the routing table 483 consists of: 485 - Setting the destination prefix and length to those in the RTE. 487 - Setting the metric to the newly calculated metric (as described 488 above). 490 - Set the next hop address to be the address of the router from which 491 the datagram came. 493 - Initialize the timeout for the route. If the garbage-collection 494 timer is running for this route, stop it (see section 2.3 for a 495 discussion of the timers). 497 - Set the route change flag. 499 - Signal the output process to trigger an update (see section 2.5). 501 If there is an existing route, compare the next hop address to the 502 address of the router from which the datagram came. If this datagram 503 is from the same router as the existing route, reinitialize the 504 timeout. Next, compare the metrics. If the datagram is from the 505 same router as the existing route, and the new metric is different 506 than the old one; or, if the new metric is lower than the old one; do 507 the following actions: 509 - Adopt the route from the datagram. That is, put the new metric in, 510 and adjust the next hop address (if necessary). 512 - Set the route change flag and signal the output process to trigger 513 an update. 515 - If the new metric is infinity, start the deletion process 516 (described above); otherwise, re-initialize the timeout. 518 If the new metric is infinity, the deletion process begins for the 519 route, which is no longer used for routing packets. Note that the 520 deletion process is started only when the metric is first set to 521 infinity. If the metric was already infinity, then a new deletion 522 process is not started. 524 If the new metric is the same as the old one, it is simplest to do 525 nothing further (beyond reinitializing the timeout, as specified 526 above); but, there is a heuristic which could be applied. Normally, 527 it is senseless to replace a route if the new route has the same 528 metric as the existing route; this would cause the route to bounce 529 back and forth, which would generate an intolerable number of 530 triggered updates. However, if the existing route is showing signs 531 of timing out, it may be better to switch to an equally-good 532 alternative route immediately, rather than waiting for the timeout to 533 happen. Therefore, if the new metric is the same as the old one, 534 examine the timeout for the existing route. If it is at least 535 halfway to the expiration point, switch to the new route. This 536 heuristic is optional, but highly recommended. 538 Any entry that fails these tests is ignored, as it is no better than 539 the current route. 541 2.5 Output Processing 543 This section describes the processing used to create response 544 messages that contain all or part of the routing table. This 545 processing may be triggered in any of the following ways: 547 - By input processing, when a Request is received. In this case, the 548 Response is sent to only one destination. 550 - By the regular routing update. Every 30 seconds, a Response 551 containing the whole routing table is sent to every neighboring 552 router. 554 - By triggered updates. Whenever the metric for a route is changed, 555 an update is triggered. 557 The special processing required for a Request is described in section 558 2.4.1. 560 When a Response is to be sent to all neighbors (i.e., a regular or 561 triggered update), a Response message is directed to the router at 562 the far end of each connected point-to-point link, and is multicast 563 on all connected networks that support broadcasting. Thus, one 564 Response is prepared for each directly-connected network, and sent to 565 the appropriate address (direct or multicast). In most cases, this 566 reaches all neighboring routers. However, there are some cases where 567 this may not be good enough. This may involve a network that is not 568 a broadcast network (e.g., the ARPANET), or a situation involving 569 dumb routers. In such cases, it may be necessary to specify an 570 actual list of neighboring routers and send a datagram to each one 571 explicitly. It is left to the implementor to determine whether such 572 a mechanism is needed, and to define how the list is specified. 574 2.5.1 Triggered Updates 576 Triggered updates require special handling for two reasons. First, 577 experience shows that triggered updates can cause excessive loads on 578 networks with limited capacity or networks with many routers on them. 579 Therefore, the protocol requires that implementors include provisions 580 to limit the frequency of triggered updates. After a triggered 581 update is sent, a timer should be set for a random interval between 1 582 and 5 seconds. If other changes that would trigger updates occur 583 before the timer expires, a single update is triggered when the timer 584 expires. The timer is then reset to another random value between 1 585 and 5 seconds. Triggered updates may be suppressed if a regular 586 update is due by the time the triggered update would be sent. 588 Second, triggered updates do not need to include the entire routing 589 table. In principle, only those routes which have changed need to be 590 included. Therefore messages generated as part of a triggered update 591 must include at least those routes that have their route change flag 592 set. They may include additional routes, at the discretion of the 593 implementor; however, sending complete routing updates is strongly 594 discouraged. When a triggered update is processed, messages should 595 be generated for every directly-connected network. Split Horizon 596 processing is done when generating triggered updates as well as 597 normal updates (see section 2.6). If, after Split Horizon processing 598 for a given network, a changed route will appear unchanged on that 599 network (e.g., it appears with an infinite metric), the route need 600 not be sent. If no routes need be sent on that network, the update 601 may be omitted. Once all of the triggered updates have been 602 generated, the route change flags should be cleared. 604 If input processing is allowed while output is being generated, 605 appropriate interlocking must be done. The route change flags should 606 not be changed as a result of processing input while a triggered 607 update message is being generated. 609 The only difference between a triggered update and other update 610 messages is the possible omission of routes that have not changed. 611 The remaining mechanisms, described in the next section, must be 612 applied to all updates. 614 2.5.2 Generating Response Messages 616 This section describes how a Response message is generated for a 617 particular directly-connected network: 619 The IPv6 source address must be the link-local address of the address 620 of the sending router's interface. This is important because the 621 source address is put into routing tables (as the next hop) in the 622 routers which receive this Response. If an incorrect source address 623 is used, other routers may be unable to route datagrams. Sometimes 624 routers are set up with multiple IPv6 addresses on a single physical 625 interface. Normally, this means that several logical IPv6 networks 626 are being carried over one physical medium. 628 Set the version number to the current version of RIPng. The version 629 described in this document is version 1. Set the command to 630 Response. Set the bytes labeled "must be zero" to zero. Start 631 filling in RTEs. Recall that the maximum datagram size is limited by 632 the network's MTU. When there is no more space in the datagram, send 633 the current Response and start a new one. 635 To fill in the RTEs, examine each route in the routing table. If a 636 triggered update is being generated, only entries whose route change 637 flags are set need be included. If, after Split Horizon processing, 638 the route should not be included, skip it. If the route is to be 639 included, then the destination prefix, prefix length, and metric are 640 put into the RTE. Routes must be included in the datagram even if 641 their metrics are infinite. 643 2.6 Split Horizon 645 Split Horizon is a algorithm for avoiding problems caused by 646 including routes in updates sent to the gateway from which they were 647 learned. The basic split horizon algorithm omits routes learned from 648 one neighbor in updates sent to that neighbor. In the case of a 649 broadcast network, all routes learned from any neighbor on that 650 network are omitted from updates sent on that network. 652 Split Horizon with Poisoned Reverse (more simply, Poison Reverse) 653 does include such routes in updates, but sets their metrics to 654 infinity. In effect, advertising the fact that there routes are not 655 reachable. This is the preferred method of operation; however, 656 implementations should provide a per-interface control allowing no 657 horizoning, split horizoning, and poisoned reverse to be selected. 659 For a theoretical discussion of Split Horizon and Poison Reverse, and 660 why they are needed, see section 2.1.1 of [1]. 662 3. Control Functions 664 This section describes administrative controls. These are not part 665 of the protocol per se; however, experience with existing networks 666 suggests that they are important. Because they are not a necessary 667 part of the protocol, they are considered optional. However, it is 668 strongly recommend that at least some of them be included in every 669 implementation. These controls are intended primarily to allow RIPng 670 to be connected to networks whose routing may be unstable or subject 671 to errors. Here are some examples: 673 - It is sometimes desirable to restrict the routers from which 674 updates will be accepted, or to which updates will be sent. This 675 is usually done for administrative, routing policy reasons. 677 - A number of sites limit the set of networks that they allow in 678 Response messages. Organization A may have a connection to 679 organization B that they use for direct communication. For 680 security or performance reasons A may not be willing to give other 681 organizations access to that connection. In such a case, A should 682 not include B's networks in updates that A sends to third parties. 684 Here are some typical controls. Note, however, that the RIPng 685 protocol does not require these or any other controls. 687 - A neighbor list which allows the network administrator to be able 688 to define a list of neighbors for each router. A router would 689 accept response messages only from routers on its list of 690 neighbors. A similar list for target routers should also be 691 available to the administrator. By default, no restrictions are 692 defined. 694 - A filter for specific destinations would permit the network 695 administrator to be able to specify a list of destination prefixes 696 to allow or disallow. The list would be associated with a 697 particular interface in the incoming and/or outgoing directions. 698 Only allowed networks would be mentioned in Response messages going 699 out or processed in Response messages coming in. If a list of 700 allowed prefixes is specified, all other prefixes are disallowed. 701 If a list of disallowed prefixes is specified, all other prefixes 702 are allowed. By default, no filters are applied. 704 4. Security Considerations 706 No security is defined for RIPng because IPv6 provides sufficient 707 security to protect RIPng packets. 709 References 711 [1] Hedrick, C., "Routing Information Protocol", Request For Comments 712 (RFC) 1058, Rutgers University, June 1988. 714 [2] Malkin, G., "RIP Version 2 - Carrying Additional Information", 715 Request For Comments (RFC) 1723, Xylogics, Inc., November, 1994. 717 [3] Hinden, R., "IP Next Generation Overview", 718 draft-hinden-ipng-overview-00.txt, October 1994 720 [4] Bellman, R. E., "Dynamic Programming", Princeton University 721 Press, Princeton, N.J., 1957. 723 [5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", 724 Prentice-Hall, Englewood Cliffs, N.J., 1987. 726 [6] Braden, R., and Postel, J., "Requirements for Internet Gateways", 727 USC/Information Sciences Institute, RFC-1009, June 1987. 729 [7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M., 730 "Pup: An Internetwork Architecture", IEEE Transactions on 731 Communications, April 1980. 733 [8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks", 734 Princeton University Press, Princeton, N.J., 1962. 736 [9] Xerox Corp., "Internet Transport Protocols", Xerox System 737 Integration Standard XSIS 028112, December 1981. 739 [10] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery for 740 IP Version 6 (IPv6)", draft-ietf-ipngwg-discovery-04.txt, 741 February 1996. 743 Author's Address 745 Gary Scott Malkin 746 Xylogics, Inc. 747 53 Third Avenue 748 Burlington, MA 01803 750 Phone: (617) 272-8140 751 EMail: gmalkin@Xylogics.COM