idnits 2.17.1 draft-ietf-rip-ripng-03.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-19) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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 (June 1996) is 10170 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' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Draft-ietf-rip-ripng-03.txt G. Malkin/Xylogics 2 R. Minnear/Ipsilon Networks 3 June 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 doc- 20 uments of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute work- 22 ing 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 mate- 27 rial 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 Hedrick [1]. The modifications reflect RIP-2 and IPv6 enhancements, 39 but the original wording is his. 41 We'd like to thank Dennis Ferguson and Thomas Narten for their input. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1 Theoretical Underpinnings . . . . . . . . . . . . . . . . . 4 47 1.2 Limitations of the Protocol . . . . . . . . . . . . . . . . 4 48 2. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4 49 2.1 Message Format . . . . . . . . . . . . . . . . . . . . . . . 6 50 2.1.1 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . 8 51 2.2 Addressing Considerations . . . . . . . . . . . . . . . . . 9 52 2.3 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 53 2.4 Input Processing . . . . . . . . . . . . . . . . . . . . . . 11 54 2.4.1 Request Messages . . . . . . . . . . . . . . . . . . . . . 11 55 2.4.2 Response Messages . . . . . . . . . . . . . . . . . . . . 12 56 2.5 Output Processing . . . . . . . . . . . . . . . . . . . . . 14 57 2.5.1 Triggered Updates . . . . . . . . . . . . . . . . . . . . 15 58 2.5.2 Generating Response Messages . . . . . . . . . . . . . . . 16 59 2.6 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 17 60 3. Control Functions . . . . . . . . . . . . . . . . . . . . . . 17 61 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 18 62 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 65 1. Introduction 67 This memo describes one protocol in a series of routing protocols 68 based on the Bellman-Ford (or distance vector) algorithm. This algo- 69 rithm has been used for routing computations in computer networks 70 since the early days of the ARPANET. The particular packet formats 71 and protocol described here are based on the program "routed," which 72 is included with the Berkeley distribution of Unix. 74 In an international network, such as the Internet, it is very 75 unlikely that a single routing protocol will used for the entire net- 76 work. Rather, the network will be organized as a collection of 77 Autonomous Systems (AS), each of which will, in general, be adminis- 78 tered by a single entity. Each AS will have its own routing technol- 79 ogy, which may differ among AS's. The routing protocol used within 80 an AS is referred to as an Interior Gateway Protocol (IGP). A sepa- 81 rate protocol, called an Exterior Gateway Protocol (EGP), is used to 82 transfer routing information among the AS's. RIPng was designed to 83 work as an IGP in moderate-size AS's. It is not intended for use in 84 more complex environments. For information on the context into which 85 RIP version 1 (RIP-1) is expected to fit, see Braden and Postel [6]. 87 RIPng is one of a class of algorithms known as Distance Vector algo- 88 rithms. The earliest description of this class of algorithms known 89 to the author is in Ford and Fulkerson [8]. Because of this, they 90 are sometimes known as Ford-Fulkerson algorithms. The term Bellman- 91 Ford is also used, and derives from the fact that the formulation is 92 based on Bellman's equation [4]. The presentation in this document 93 is closely based on [5]. This document contains a protocol specifi- 94 cation. For an introduction to the mathematics of routing algo- 95 rithms, see [1]. The basic algorithms used by this protocol were 96 used in computer routing as early as 1969 in the ARPANET. However, 97 the specific ancestry of this protocol is within the Xerox network 98 protocols. The PUP protocols [7] used the Gateway Information Proto- 99 col to exchange routing information. A somewhat updated version of 100 this protocol was adopted for the Xerox Network Systems (XNS) archi- 101 tecture, with the name Routing Information Protocol [9]. Berkeley's 102 routed is largely the same as the Routing Information Protocol, with 103 XNS addresses replaced by a more general address format capable of 104 handling IPv4 and other types of address, and with routing updates 105 limited to one every 30 seconds. Because of this similarity, the 106 term Routing Information Protocol (or just RIP) is used to refer to 107 both the XNS protocol and the protocol used by routed. 109 1.1 Theoretical Underpinnings 111 An introduction to the theory and math behind Distance Vector proto- 112 cols is provided in [1]. It has not been incorporated in this docu- 113 ment for the sake of brevity. 115 1.2 Limitations of the Protocol 117 This protocol does not solve every possible routing problem. As men- 118 tioned above, it is primarily intended for use as an IGP in networks 119 of moderate size. In addition, the following specific limitations 120 are be mentioned: 122 - The protocol is limited to networks whose longest path (the net- 123 work's diameter) is 15 hops. The designers believe that the basic 124 protocol design is inappropriate for larger networks. Note that 125 this statement of the limit assumes that a cost of 1 is used for 126 each network. This is the way RIPng is normally configured. If 127 the system administrator chooses to use larger costs, the upper 128 bound of 15 can easily become a problem. 130 - The protocol depends upon "counting to infinity" to resolve certain 131 unusual situations (see section 2.2 in [1]). If the system of net- 132 works has several hundred networks, and a routing loop was formed 133 involving all of them, the resolution of the loop would require 134 either much time (if the frequency of routing updates were limited) 135 or bandwidth (if updates were sent whenever changes were detected). 136 Such a loop would consume a large amount of network bandwidth 137 before the loop was corrected. We believe that in realistic cases, 138 this will not be a problem except on slow lines. Even then, the 139 problem will be fairly unusual, since various precautions are taken 140 that should prevent these problems in most 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 com- 152 puting 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 155 [10]. Any router that uses RIPng is assumed to have interfaces to 156 one or more networks, otherwise it isn't really a router. These are 157 referred to as its directly-connected networks. The protocol relies 158 on access to certain information about each of these networks, the 159 most important of which is its metric. The RIPng metric of a network 160 is an integer between 1 and 15, inclusive. It is set in some manner 161 not specified in this protocol; however, given the maximum path limit 162 of 15, a value of 1 is usually used. Implementations should allow 163 the system administrator to set the metric of each network. In addi- 164 tion to the metric, each network will have an IPv6 destination 165 address prefix and prefix length associated with it. These are to be 166 set by the system administrator in a manner not specified in this 167 protocol. 169 Each router that implements RIPng is assumed to have a routing table. 170 This table has one entry for every destination that is reachable 171 throughout the system operating RIPng. Each entry contains at least 172 the following information: 174 - The IPv6 prefix of the destination. 176 - A metric, which represents the total cost of getting a datagram 177 from the router to that destination. This metric is the sum of the 178 costs associated with the networks that would be traversed to get 179 to the destination. 181 - The IPv6 address of the next router along the path to the destina- 182 tion (i.e., the next hop). If the destination is on one of the 183 directly-connected networks, this item is not needed. 185 - A flag to indicate that information about the route has changed 186 recently. This will be referred to as the "route change flag." 188 - Various timers associated with the route. See section 2.3 for more 189 details on timers. 191 The entries for the directly-connected networks are set up by the 192 router using information gathered by means not specified in this pro- 193 tocol. The metric for a directly-connected network is set to the 194 cost of that network. As mentioned, 1 is the usual cost. In that 195 case, the RIPng metric reduces to a simple hop-count. More complex 196 metrics may be used when it is desirable to show preference for some 197 networks over others (e.g., to indicate of differences in bandwidth 198 or reliability). 200 Implementors may also choose to allow the system administrator to 201 enter additional routes. These would most likely be routes to hosts 202 or networks outside the scope of the routing system. They are 203 referred to as "static routes." Entries for destinations other than 204 these initial ones are added and updated by the algorithms described 205 in the following sections. 207 In order for the protocol to provide complete information on routing, 208 every router in the AS must participate in the protocol. In cases 209 where multiple IGPs are in use, there must be at least one router 210 which can leak routing information between the protocols. 212 2.1 Message Format 214 RIPng is a UDP-based protocol. Each router that uses RIPng has a 215 routing process that sends and receives datagrams on UDP port number 216 521, the RIPng port. All communications intended for another 217 router's RIPng process are sent to the RIPng port. All routing 218 update messages are sent from the RIPng port. Unsolicited routing 219 update messages have both the source and destination port equal to 220 the RIPng port. Those sent in response to a request are sent to the 221 port from which the request came. Specific queries may be sent from 222 ports other than the RIPng port, but they must be directed to the 223 RIPng port on the target machine. 225 The RIPng packet format is: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | command (1) | version (1) | must be zero (2) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 ~ Route Table Entry 1 (20) ~ 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 ~ ... ~ 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 ~ Route Table Entry N (20) ~ 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 where each Route Table Entry (RTE) has the following format: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 ~ IPv6 prefix (16) ~ 252 | | 253 +---------------------------------------------------------------+ 254 | route tag (2) | prefix len (1)| metric (1) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 The maximum number of RTEs is defined below. 259 Field sizes are given in octets. Unless otherwise specified, fields 260 contain binary integers, in network byte order, with the most- 261 significant octet first (big-endian). Each tick mark represents one 262 bit. 264 Every message contains a RIPng header which consists of a command and 265 a version number. This document describes version 1 of the protocol 266 (see section 2.4). The command field is used to specify the purpose 267 of this message. The commands implemented in version 1 are: 269 1 - request A request for the responding system to send all or 270 part of its routing table. 272 2 - response A message containing all or part of the sender's rout- 273 ing table. This message may be sent in response to a 274 request, or it may be an unsolicited routing update 275 generated by the sender. 277 For each of these message types, the remainder of the datagram con- 278 tains a list of RTEs. Each RTE in this list contains a destination 279 prefix, the number of significant bits in the prefix, and the cost to 280 reach that destination (metric). 282 The destination prefix is the usual 128-bit, IPv6 address prefix 283 stored as 16 octets in network byte order. 285 The route tag field is an attribute assigned to a route which must be 286 preserved and readvertised with a route. The intended use of the 287 route tag is to provide a method of separating "internal" RIPng 288 routes (routes for networks within the RIPng routing domain) from 289 "external" RIPng routes, which may have been imported from an EGP or 290 another IGP. 292 Routers supporting protocols other than RIPng should be configurable 293 to allow the route tag to be configured for routes imported from dif- 294 ferent sources. For example, routes imported from an EGP should be 295 able to have their route tag either set to an arbitrary value, or at 296 least to the number of the Autonomous System from which the routes 297 were learned. 299 Other uses of the route tag are valid, as long as all routers in the 300 RIPng domain use it consistently. 302 The prefix length field is the length in bits of the significant part 303 of the prefix (a value between 0 and 128 inclusive) starting from the 304 left of the prefix. 306 The metric field contains a value between 1 and 15 inclusive, speci- 307 fying the current metric for the destination; or the value 16 (infin- 308 ity), which indicates that the destination is not reachable. 310 The maximum datagram size is limited by the MTU of the medium over 311 which the protocol is being used. Since an unsolicited RIPng update 312 is never propagated across a router, there is no danger of an MTU 313 mismatch. The determination of the number of RTEs which may be put 314 into a given message is a function of the medium's MTU, the number of 315 octets of header information preceeding the RIPng message, the size 316 of the RIPng header, and the size of an RTE. The formula is: 318 +- -+ 319 | MTU - sizeof(IPv6_hdrs) - UDP_hdrlen - RIPng_hdrlen | 320 #RTEs = INT | --------------------------------------------------- | 321 | RTE_size | 322 +- -+ 324 2.1.1 Next Hop 326 RIPng provides the ability to specify the immediate next hop IPv6 327 address to which packets to a destination specified by a route table 328 entry (RTE) should be forwarded in much the same way as RIP-2 [2]. 329 In RIP-2, each route table entry has a next hop field. Including a 330 next hop field for each RTE in RIPng would nearly double the size of 331 the RTE. Therefore, in RIPng, the next hop is specified by a special 332 RTE and applies to all of the address RTEs following the next hop RTE 333 until the end of the message or until another next hop RTE is encoun- 334 tered. 336 A next hop RTE is identified by a value of 0xFF in the metric field 337 of an RTE. The prefix field specifies the IPv6 address of the next 338 hop. The route tag and prefix length in the next hop RTE must be set 339 to zero on sending and ignored on receiption. 341 The next hop Route Table Entry (RTE) has the following format: 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | 347 ~ IPv6 next hop address (16) ~ 348 | | 349 +---------------------------------------------------------------+ 350 | must be zero (2) |must be zero(1)| 0xFF | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Specifying a value of 0:0:0:0:0:0:0:0 in the prefix field of a next 354 hop RTE indicates that the next hop address should be the originator 355 of the RIPng advertisement. An address specified as a next hop must 356 be a link-local address. 358 The purpose of the next hop RTE is to eliminate packets being routed 359 through extra hops in the system. It is particularly useful when 360 RIPng is not being run on all of the routers on a network. Note that 361 next hop RTE is "advisory". That is, if the provided information is 362 ignored, a possibly sub-optimal, but absolutely valid, route may be 363 taken. If the received next hop address is not a link-local address, 364 it should be treated as 0:0:0:0:0:0:0:0. 366 2.2 Addressing Considerations 368 The distinction between network, subnet and host routes does not need 369 to be made for RIPng because an IPv6 address prefix is unambiguous. 371 Any prefix with a prefix length of zero is used to designate a 372 default route. It is suggested that the prefix 0:0:0:0:0:0:0:0 be 373 used when specifying the default route, though the prefix is essen- 374 tially ignored. A default route is used when it is not convenient to 375 list every possible network in the RIPng updates, and when one or 376 more routers in the system are prepared to handle traffic to the net- 377 works that are not explicitly listed. These "default routers" use 378 the default route as a path for all datagrams for which they have no 379 explicit route. The decision as to how a router becomes a default 380 router (i.e., how a default route entry is created) is left to the 381 implementor. In general, the system administrator will be provided 382 with a way to specify which routers should create and advertise 383 default route entries. If this mechanism is used, the implementation 384 should allow the network administrator to choose the metric associ- 385 ated with the default route advertisement. This will make it possi- 386 ble to establish a precedence amoung multiple default routers. The 387 default route entries are handled by RIPng in exactly the same manner 388 as any other destination prefix. System administrators should take 389 care to make sure that default routes do not propagate further than 390 is intended. Generally, each AS has its own preferred default 391 router. Therefore, default routes should generally not leave the 392 boundary of an AS. The mechanisms for enforcing this restriction are 393 not specified in this document. 395 2.3 Timers 397 This section describes all events that are triggered by timers. 399 Every 30 seconds, the RIPng process is awakened to send an unso- 400 licited Response message, containing the complete routing table (see 401 section 2.6 on Split Horizon), to every neighboring router. When 402 there are many routers on a single network, there is a tendency for 403 them to synchronize with each other such that they all issue updates 404 at the same time. This can happen whenever the 30 second timer is 405 affected by the processing load on the system. It is undesirable for 406 the update messages to become synchronized, since it can lead to 407 unnecessary collisions on broadcast networks (see [13] for more 408 details). Therefore, implementations are required to take one of two 409 precautions: 411 - The 30-second updates are triggered by a clock whose rate is not 412 affected by system load or the time required to service the previ- 413 ous update timer. 415 - The 30-second timer is offset by a small random time (+/- 0 to 15 416 seconds) each time it is set. The offset is derived from: 0.5 * 417 the update period (i.e. 30). 419 There are two timers associated with each route, a "timeout" and a 420 "garbage-collection time." Upon expiration of the timeout, the route 421 is no longer valid; however, it is retained in the routing table for 422 a short time so that neighbors can be notified that the route has 423 been dropped. Upon expiration of the garbage-collection timer, the 424 route is finally removed from the routing table. 426 The timeout is initialized when a route is established, and any time 427 an update message is received for the route. If 180 seconds elapse 428 from the last time the timeout was initialized, the route is consid- 429 ered to have expired, and the deletion process described below begins 430 for that route. 432 Deletions can occur for one of two reasons: the timeout expires, or 433 the metric is set to 16 because of an update received from the cur- 434 rent router (see section 2.4.2 for a discussion of processing updates 435 from other routers). In either case, the following events happen: 437 - The garbage-collection timer is set for 120 seconds. 439 - The metric for the route is set to 16 (infinity). This causes the 440 route to be removed from service. 442 - The route change flag is to indicate that this entry has been 443 changed. 445 - The output process is signalled to trigger a response. 447 Until the garbage-collection timer expires, the route is included in 448 all updates sent by this router. When the garbage-collection timer 449 expires, the route is deleted from the routing table. 451 Should a new route to this network be established while the garbage- 452 collection timer is running, the new route will replace the one that 453 is about to be deleted. In this case the garbage-collection timer 454 must be cleared. 456 Triggered updates also use a small timer; however, this is best 457 described in section 2.5.1. 459 2.4 Input Processing 461 This section will describe the handling of datagrams received on the 462 RIPng port. Processing will depend upon the value in the command 463 field. Version 1 supports only two commands: Request and Response. 465 2.4.1 Request Messages 467 A Request is used to ask for a response containing all or part of a 468 router's routing table. Normally, Requests are sent as multicasts, 469 from the RIPng port, by routers which have just come up and are seek- 470 ing to fill in their routing tables as quickly as possible. However, 471 there may be situations (e.g., router monitoring) where the routing 472 table of only a single router is needed. In this case, the Request 473 should be sent directly to that router from a UDP port other than the 474 RIPng port. If such a Request is received, the router responds 475 directly to the requestor's address and port with a globally valid 476 source address since the requestor may not reside on the directly 477 attached network. 479 The Request is processed entry by entry. If there are no entries, no 480 response is given. There is one special case. If there is exactly 481 one entry in the request, and it has a destination prefix of zero and 482 a metric of infinity (i.e., 16), then this is a request to send the 483 entire routing table. In that case, a call is made to the output 484 process to send the routing table to the requesting address/port. 485 Except for this special case, processing is quite simple. Examine 486 the list of RTEs in the Request one by one. For each entry, look up 487 the destination in the router's routing database and, if there is a 488 route, put that route's metric in the metric field of the RTE. If 489 there is no explicit route to the specified destination, put infinity 490 in the metric field. Once all the entries have been filled in, 491 change the command from Request to Response and send the datagram 492 back to the requestor. 494 Note that there is a difference in metric handling for specific and 495 whole-table requests. If the request is for a complete routing 496 table, normal output processing is done, including Split Horizon (see 497 section 2.6 on Split Horizon). If the request is for specific 498 entries, they are looked up in the routing table and the information 499 is returned as is; no Split Horizon processing is done. The reason 500 for this distinction is the expectation that these requests are 501 likely to be used for different purposes. When a router first comes 502 up, it multicasts a Request on every connected network asking for a 503 complete routing table. It is assumed that these complete routing 504 tables are to be used to update the requestor's routing table. For 505 this reason, Split Horizon must be done. It is further assumed that 506 a Request for specific networks is made only by diagnostic software, 507 and is not used for routing. In this case, the requester would want 508 to know the exact contents of the routing table and would not want 509 any information hidden or modified. 511 2.4.2 Response Messages 513 A Response can be received for one of several different reasons: 515 - response to a specific query 516 - regular update (unsolicited response) 517 - triggered update caused by a route change 519 Processing is the same no matter why the Response was generated. 521 Because processing of a Response may update the router's routing 522 table, the Response must be checked carefully for validity. The 523 Response must be ignored if it is not from the RIPng port. The data- 524 gram's IPv6 source address should be checked to see whether the data- 525 gram is from a valid neighbor; the source of the datagram must be a 526 link-local address. It is also worth checking to see whether the 527 response is from one of the router's own addresses. Interfaces on 528 broadcast networks may receive copies of their own multicasts immedi- 529 ately. If a router processes its own output as new input, confusion 530 is likely, and such datagrams must be ignored. As an additional 531 check, periodic advertisements must have their hop counts set to 255, 532 and inbound, multicast packets sent from the RIPng port (i.e. peri- 533 odic advertisement or triggered update packets) must be examined to 534 ensure that the hop count is 255. This absolutely guarantees that a 535 packet is from a neighbor, because any intermediate node would have 536 decremented the hop count. Queries and their responses may still 537 cross intermediate nodes and therefore do not require the hop count 538 test to be done. 540 Once the datagram as a whole has been validated, process the RTEs in 541 the Response one by one. Again, start by doing validation. Incor- 542 rect metrics and other format errors usually indicate misbehaving 543 neighbors and should probably be brought to the administrator's 544 attention. For example, if the metric is greater than infinity, 545 ignore the entry but log the event. The basic validation tests are: 547 - is the destination prefix valid (e.g., not a multicast prefix) 548 - is the prefix length valid (i.e., between 0 and 128, inclusive) 549 - is the metric valid (i.e., between 1 and 16, inclusive) 551 If any check fails, ignore that entry and proceed to the next. 552 Again, logging the error is probably a good idea. 554 Once the entry has been validated, update the metric by adding the 555 cost of the network on which the message arrived. If the result is 556 greater than infinity, use infinity. That is, 558 metric = MIN (metric + cost, infinity) 560 Now, check to see whether there is already an explicit route for the 561 destination prefix. If there is no such route, add this route to the 562 routing table, unless the metric is infinity (there is no point in 563 adding a route which unusable). Adding a route to the routing table 564 consists of: 566 - Setting the destination prefix and length to those in the RTE. 568 - Setting the metric to the newly calculated metric (as described 569 above). 571 - Set the next hop address to be the address of the router from which 572 the datagram came or the next hop address specified by a next hop 573 RTE. 575 - Initialize the timeout for the route. If the garbage-collection 576 timer is running for this route, stop it (see section 2.3 for a 577 discussion of the timers). 579 - Set the route change flag. 581 - Signal the output process to trigger an update (see section 2.5). 583 If there is an existing route, compare the next hop address to the 584 address of the router from which the datagram came. If this datagram 585 is from the same router as the existing route, reinitialize the time- 586 out. Next, compare the metrics. If the datagram is from the same 587 router as the existing route, and the new metric is different than 588 the old one; or, if the new metric is lower than the old one; do the 589 following actions: 591 - Adopt the route from the datagram. That is, put the new metric in, 592 and adjust the next hop address (if necessary). 594 - Set the route change flag and signal the output process to trigger 595 an update. 597 - If the new metric is infinity, start the deletion process 598 (described above); otherwise, re-initialize the timeout. 600 If the new metric is infinity, the deletion process begins for the 601 route, which is no longer used for routing packets. Note that the 602 deletion process is started only when the metric is first set to 603 infinity. If the metric was already infinity, then a new deletion 604 process is not started. 606 If the new metric is the same as the old one, it is simplest to do 607 nothing further (beyond reinitializing the timeout, as specified 608 above); but, there is a heuristic which could be applied. Normally, 609 it is senseless to replace a route if the new route has the same met- 610 ric as the existing route; this would cause the route to bounce back 611 and forth, which would generate an intolerable number of triggered 612 updates. However, if the existing route is showing signs of timing 613 out, it may be better to switch to an equally-good alternative route 614 immediately, rather than waiting for the timeout to happen. There- 615 fore, if the new metric is the same as the old one, examine the time- 616 out for the existing route. If it is at least halfway to the expira- 617 tion point, switch to the new route. This heuristic is optional, but 618 highly recommended. 620 Any entry that fails these tests is ignored, as it is no better than 621 the current route. 623 2.5 Output Processing 625 This section describes the processing used to create response mes- 626 sages that contain all or part of the routing table. This processing 627 may be triggered in any of the following ways: 629 - By input processing, when a Request is received. In this case, the 630 Response is sent to only one destination (i.e. the unicast address 631 of the requestor). 633 - By the regular routing update. Every 30 seconds, a Response con- 634 taining the whole routing table is sent to every neighboring 635 router. 637 - By triggered updates. Whenever the metric for a route is changed, 638 an update is triggered. 640 The special processing required for a Request is described in section 641 2.4.1. 643 When a Response is to be sent to all neighbors (i.e., a regular or 644 triggered update), a Response message is multicast to the multicast 645 group FF02::9, the all-rip-routers multicast group, on all connected 646 networks that support broadcasting or are point-to-point links. RIPng 647 handles point-to-point links just like multicast links as multicast- 648 ing can be trivially provided on such links. Thus, one Response is 649 prepared for each directly-connected network, and sent to the all- 650 rip-routers multicast group. In most cases, this reaches all neigh- 651 boring routers. However, there are some cases where this may not be 652 good enough. This may involve a network that is not a broadcast net- 653 work (e.g., the ARPANET), or a situation involving dumb routers. In 654 such cases, it may be necessary to specify an actual list of neigh- 655 boring routers and send a datagram to each one explicitly. It is 656 left to the implementor to determine whether such a mechanism is 657 needed, and to define how the list is specified. 659 2.5.1 Triggered Updates 661 Triggered updates require special handling for two reasons. First, 662 experience shows that triggered updates can cause excessive loads on 663 networks with limited capacity or networks with many routers on them. 664 Therefore, the protocol requires that implementors include provisions 665 to limit the frequency of triggered updates. After a triggered 666 update is sent, a timer should be set for a random interval between 1 667 and 5 seconds. If other changes that would trigger updates occur 668 before the timer expires, a single update is triggered when the timer 669 expires. The timer is then reset to another random value between 1 670 and 5 seconds. Triggered updates may be suppressed if a regular 671 update is due by the time the triggered update would be sent. 673 Second, triggered updates do not need to include the entire routing 674 table. In principle, only those routes which have changed need to be 675 included. Therefore messages generated as part of a triggered update 676 must include at least those routes that have their route change flag 677 set. They may include additional routes, at the discretion of the 678 implementor; however, sending complete routing updates is strongly 679 discouraged. When a triggered update is processed, messages should 680 be generated for every directly-connected network. Split Horizon 681 processing is done when generating triggered updates as well as nor- 682 mal updates (see section 2.6). If, after Split Horizon processing 683 for a given network, a changed route will appear unchanged on that 684 network (e.g., it appears with an infinite metric), the route need 685 not be sent. If no routes need be sent on that network, the update 686 may be omitted. Once all of the triggered updates have been gener- 687 ated, the route change flags should be cleared. 689 If input processing is allowed while output is being generated, 690 appropriate interlocking must be done. The route change flags should 691 not be changed as a result of processing input while a triggered 692 update message is being generated. 694 The only difference between a triggered update and other update mes- 695 sages is the possible omission of routes that have not changed. The 696 remaining mechanisms, described in the next section, must be applied 697 to all updates. 699 2.5.2 Generating Response Messages 701 This section describes how a Response message is generated for a par- 702 ticular directly-connected network: 704 The IPv6 source address must be a link-local address of the possible 705 addresses of the sending router's interface, except when replying to 706 a unicast Request Message from a port other than the RIPng port. In 707 the latter case, the source address must be a globaly valid address. 708 In the former case, it is important to use a link-local address 709 because the source address is put into routing tables (as the next 710 hop) in the routers which receive this Response. If an incorrect 711 source address is used, other routers may be unable to route data- 712 grams. Sometimes routers are set up with multiple IPv6 addresses on 713 a single physical interface. Normally, this means that several logi- 714 cal IPv6 networks are being carried over one physical medium. It is 715 possible that a router may have multiple link-local addresses for a 716 single interface. In this case, the router must only originate a sin- 717 gle Response message with a source address of the designated link- 718 local address for a given interface. The choice of which link-local 719 address to use should only change when the current choice is no 720 longer valid. This is necessary because nodes receiving Response 721 messages use the source address to identify the sender. If multiple 722 packets from the same router contain different source addresses, 723 nodes will assume they come from different routers, leading to unde- 724 sirable behavior. 726 Set the version number to the current version of RIPng. The version 727 described in this document is version 1. Set the command to 728 Response. Set the bytes labeled "must be zero" to zero. Start fill- 729 ing in RTEs. Recall that the maximum datagram size is limited by the 730 network's MTU. When there is no more space in the datagram, send the 731 current Response and start a new one. 733 To fill in the RTEs, examine each route in the routing table. If a 734 triggered update is being generated, only entries whose route change 735 flags are set need be included. If, after Split Horizon processing, 736 the route should not be included, skip it. If the route is to be 737 included, then the destination prefix, prefix length, and metric are 738 put into the RTE. The route tag is filled in as defined in section 739 2.1. Routes must be included in the datagram even if their metrics 740 are infinite. 742 2.6 Split Horizon 744 Split Horizon is a algorithm for avoiding problems caused by includ- 745 ing routes in updates sent to the gateway from which they were 746 learned. The basic split horizon algorithm omits routes learned from 747 one neighbor in updates sent to that neighbor. In the case of a 748 broadcast network, all routes learned from any neighbor on that net- 749 work are omitted from updates sent on that network. 751 Split Horizon with Poisoned Reverse (more simply, Poison Reverse) 752 does include such routes in updates, but sets their metrics to infin- 753 ity. In effect, advertising the fact that there routes are not 754 reachable. This is the preferred method of operation; however, 755 implementations should provide a per-interface control allowing no 756 horizoning, split horizoning, and poisoned reverse to be selected. 758 For a theoretical discussion of Split Horizon and Poison Reverse, and 759 why they are needed, see section 2.1.1 of [1]. 761 3. Control Functions 763 This section describes administrative controls. These are not part 764 of the protocol per se; however, experience with existing networks 765 suggests that they are important. Because they are not a necessary 766 part of the protocol, they are considered optional. However, it is 767 strongly recommend that at least some of them be included in every 768 implementation. These controls are intended primarily to allow RIPng 769 to be connected to networks whose routing may be unstable or subject 770 to errors. Here are some examples: 772 - It is sometimes desirable to restrict the routers from which 773 updates will be accepted, or to which updates will be sent. This 774 is usually done for administrative, routing policy reasons. 776 - A number of sites limit the set of networks that they allow in 777 Response messages. Organization A may have a connection to organi- 778 zation B that they use for direct communication. For security or 779 performance reasons A may not be willing to give other organiza- 780 tions access to that connection. In such a case, A should not 781 include B's networks in updates that A sends to third parties. 783 Here are some typical controls. Note, however, that the RIPng proto- 784 col does not require these or any other controls. 786 - A neighbor list which allows the network administrator to be able 787 to define a list of neighbors for each router. A router would 788 accept response messages only from routers on its list of neigh- 789 bors. A similar list for target routers should also be available 790 to the administrator. By default, no restrictions are defined. 792 - A filter for specific destinations would permit the network admin- 793 istrator to be able to specify a list of destination prefixes to 794 allow or disallow. The list would be associated with a particular 795 interface in the incoming and/or outgoing directions. Only allowed 796 networks would be mentioned in Response messages going out or pro- 797 cessed in Response messages coming in. If a list of allowed pre- 798 fixes is specified, all other prefixes are disallowed. If a list 799 of disallowed prefixes is specified, all other prefixes are 800 allowed. By default, no filters are applied. 802 4. Security Considerations 804 Since RIPng runs over IPv6, RIPng relies on the IP Authentication 805 Header (see [11]) and the IP Encapsulating Security Payload (see 806 [12]) to ensure integrity and authentication/confidentiality of rout- 807 ing exchanges. 809 References 811 [1] Hedrick, C., "Routing Information Protocol", Request For Comments 812 (RFC) 1058, Rutgers University, June 1988. 814 [2] Malkin, G., "RIP Version 2 - Carrying Additional Information", 815 Request For Comments (RFC) 1723, Xylogics, Inc., November, 1994. 817 [3] Hinden, R., "IP Next Generation Overview", 818 draft-hinden-ipng-overview-00.txt, October 1994 820 [4] Bellman, R. E., "Dynamic Programming", Princeton University 821 Press, Princeton, N.J., 1957. 823 [5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice- 824 Hall, Englewood Cliffs, N.J., 1987. 826 [6] Braden, R., and Postel, J., "Requirements for Internet Gateways", 827 USC/Information Sciences Institute, RFC-1009, June 1987. 829 [7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M., 830 "Pup: An Internetwork Architecture", IEEE Transactions on Commu- 831 nications, April 1980. 833 [8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks", 834 Princeton University Press, Princeton, N.J., 1962. 836 [9] Xerox Corp., "Internet Transport Protocols", Xerox System Inte- 837 gration Standard XSIS 028112, December 1981. 839 [10] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery for 840 IP Version 6 (IPv6)", draft-ietf-ipngwg-discovery-06.txt, March 841 1996. 843 [11] Atkinson, R., "IP Authentication Header", Request For Comment 844 (RFC) 1826, Naval Research Laboratory, August 1995. 846 [12] Atkinson, R., "IP Encapsulating Security Payload (ESP)", Request 847 For Comment (RFC) 1827, Naval Research Laboratory, August 1995. 849 [13] Floyd, S., and Jacobson, V., "The Synchronization of Periodic 850 Routing Messages", Proceedings of ACM SIGCOMM '93, September 851 1993. 853 Authors' Addresses 855 Gary Scott Malkin 856 Xylogics, Inc. 857 53 Third Avenue 858 Burlington, MA 01803 860 Phone: (617) 272-8140 861 EMail: gmalkin@Xylogics.COM 863 Robert E. Minnear 864 Ipsilon Networks, Inc. 865 2191 E. Bayshore Road, Suite 100 866 Palo Alto, CA 94303 868 Phone: (415) 846-4614 869 EMail: minnear@ipsilon.com