idnits 2.17.1 draft-malkin-rip-05.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 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. ** 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 Introduction section. ** 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. ** There are 21 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 1992) is 11484 days in the past. Is this intentional? 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') == Outdated reference: A later version (-03) exists of draft-ietf-ripv2-mibext-01 Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Malkin 3 Internet Draft Xylogics 4 Updates RFC 1058 November 1992 6 RIP Version 2 7 Carrying Additional Information 9 Abstract 11 This document specifies an extension of the Routing Information 12 Protocol (RIP), as defined in [1], to expand the amount of useful 13 information carried in RIP packets and to add a measure of security. 15 A companion document will define the SNMP MIB objects for RIP-2 [2]. 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 25 months. Internet Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet 27 Drafts as reference material or to cite them other than as a "working 28 draft" or "work in progress." 30 Please check the I-D abstract listing contained in each Internet 31 Draft directory to learn the current status of this or any other 32 Internet Draft. 34 It is intended that this document will be submitted to the IESG for 35 consideration as a standards document. Distribution of this document 36 is unlimited. 38 Acknowledgements 40 I would like to thank the following for their contributions to this 41 document: Fred Baker, Noel Chiappa and Vince Fuller. 43 Table of Contents 45 1. Justification . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 3 50 3.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.2 Routing Domain . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.3 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.4 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.5 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.6 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 7 59 4.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 65 Appendicies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 References . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .10 71 1. Justification 73 With the advent of OSPF and IS-IS, there are those who believe that 74 RIP is obsolete. While it is true that the newer IGP routing 75 protocols are far superior to RIP, RIP does have some advantages. 76 Primarily, in a small network, RIP has very little overhead in terms 77 of bandwidth used and configuration and management time. RIP is also 78 very easy to implement, especially in relation to the newer IGPs. 80 Additionally, there are many, many more RIP implementations in the 81 field than OSPF and IS-IS combined. It is likely to remain that way 82 for some years yet. 84 Given that RIP will be useful in many environments for some period of 85 time, it is reasonable to increase RIP's usefulness. This is 86 especially true since the gain is far greater than the expense of the 87 change. 89 2. Current RIP 91 The current RIP packet contains the minimal amount of information 92 necessary for routers to route packets through a network. It also 93 contains a large amount of unused space, owing to its origins. 95 The current RIP protocol does not consider autonomous systems and 96 IGP/EGP interactions, subnetting, and authentication since 97 implementations of these postdate RIP. The lack of subnet masks is a 98 particularly serious problem for routers since they need a subnet 99 mask to know how to determine a route. If a RIP route is a network 100 route (all non-network bits 0), the subnet mask equals the network 101 mask. However, if some of the non-network bits are set, the router 102 cannot determine the subnet mask. Worse still, the router cannot 103 determine if the RIP route is a subnet route or a host route. 104 Currently, some routers simply choose the subnet mask of the 105 interface over which the route was learned and determine the route 106 type from that. 108 3. Protocol Extensions 110 This document does not change the RIP protocol per se. Rather, it 111 provides extensions to the datagram format which allows routers to 112 share important additional information. 114 The new RIP datagram format is: 116 0 1 2 3 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Command (1) | Version (1) | Routing Domain (2) | 120 +---------------+---------------+-------------------------------+ 121 | Address Family Identifier (2) | Route Tag (2) | 122 +-------------------------------+-------------------------------+ 123 | IP Address (4) | 124 +---------------------------------------------------------------+ 125 | Subnet Mask (4) | 126 +---------------------------------------------------------------+ 127 | Next Hop (4) | 128 +---------------------------------------------------------------+ 129 | Metric (4) | 130 +---------------------------------------------------------------+ 132 The Command, Address Family Identifier (AFI), IP Address, and Metric 133 all have the meanings defined in RFC 1058. The Version field will 134 specify version number 2 for RIP datagrams which use authentication 135 or carry information in any of the newly defined fields. 137 All fields are coded in IP network byte order (big-endian). 139 3.1 Authentication 141 Since authentication is a per packet function, and since there is 142 only one 2-byte field available in the packet header, and since any 143 reasonable authentication scheme will require more than two bytes, 144 the authentication scheme for RIP version 2 will use the space of an 145 entire RIP entry. If the Address Family Identifier of the first (and 146 only the first) entry in the packet is 0xFFFF, then the remainder of 147 the entry contains the authentication. This means that there can be, 148 at most, 24 RIP entries in the remainder of the packet. If 149 authentication is not in use, then no entries in the packet should 150 have an Address Family Identifier of 0xFFFF. A RIP packet which 151 contains an authentication entry would have the following format: 153 0 1 2 3 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Command (1) | Version (1) | Routing Domain (2) | 157 +---------------+---------------+-------------------------------+ 158 | 0xFFFF | Authentication Type (2) | 159 +-------------------------------+-------------------------------+ 160 ~ Authentication (16) ~ 161 +---------------------------------------------------------------+ 162 Currently, the only Authentication Type is simple password and it 163 is type 2. The remaining 16 bytes contain the plain text password. If 164 the password is under 16 bytes, it must be left-justified and 165 padded to the right with nulls (0x00). 167 3.2 Routing Domain 169 The Routing Domain (RD) number is the number of the routing process to 170 which this update belongs. This field is used to associate the routing 171 update to a specific routing process on the receiving router. The RD 172 is needed to allow multiple, independent RIP "clouds" to co-exist on 173 the same physical wire. This gives administrators the ability to run 174 multiple, possibly parallel, instances of RIP in order to implement 175 simple policy. This means that a router operating within one routing 176 domain, or a set of routing domains, should ignore RIP packets which 177 belong to another routing domain. RD 0 is the default routing domain. 179 3.3 Route Tag 181 The Route Tag (RT) field exists as a support for EGPs. The contents 182 and use of this field are outside the scope of this protocol. However, 183 it is expected that the field will be used to carry Autonomous System 184 numbers for EGP and BGP. Any RIP system which receives a RIP entry 185 which contains a non-zero RT value must re-advertise that value. Those 186 routes which have no RT value must advertise an RT value of zero. 188 3.4 Subnet mask 190 The Subnet Mask field contains the subnet mask which is applied to 191 the IP address to yield the non-host portion of the address. If this 192 field is zero, then no subnet mask has been included for this entry. 194 For compatibility with RIP-1, it is necessary that RIP-1 subsumption 195 (see Appendix B) rules be followed in RIP-2. As a bottom line, a 196 route which RIP-2 believes is a subnet route may not, under any 197 circumstances, be viewed by RIP-1 systems as a host route. To achieve 198 this, the following applies: 200 1 - On an interface where the RIP-2 update is sent as a multicast, no 201 subsumption of routes is required. However, if any two network or 202 subnet routes have the same set of next hops and route tags, and either: 204 (a) Have differing subnet masks, and one subnet subsumes the 205 other, or 206 (b) Have the same subnet mask, and the two IP Addresses differ 207 only in the least significant bit for which the Subnet Mask 208 bit is a 1, 210 then only one route needs to be advertised. In the former case, 211 only the less restrictive network mask need be advertised, and in 212 the latter, the differing bit and its corresponding subnet mask bit 213 may be zeroed. Clearly, this operation is recursive. 215 2 - On an interface where a RIP-1 router may hear and operate on the 216 information, the subsumption rules of RFC 1058 must be obeyed; 217 information internal to another network number must never be 218 advertised into another network number, and information about a 219 more specific subnet may not be advertised where RIP-1 would 220 consider it a host route. In addition, the automatic subsumption 221 of routes in (b) above may not occur, as it would reduce route 222 information available. 224 RIP-1 compatibility is determined by the compatibility switch defined 225 in section 4.1. 227 3.5 Next Hop 229 The immediate next hop IP address to which packets to the destination 230 specified by this route entry should be forwarded. Specifying a 231 value of 0.0.0.0 in this field indicates that routing should be via 232 the originator of the RIP advertisement. An address specified as 233 a next hop must, per force, be directly reachable on the logical 234 subnet over which the advertisement is made. 236 The purpose of the Next Hop field is to eliminate packets being routed 237 through extra hops in the system. It is particularly useful when RIP 238 is not being run on all of the routers on a network. A simple example 239 is given in Appendix A. Note that Next Hop is an "advisory" field. That 240 is, if the provided information is ignored, a possibly sub-optimal, 241 but absolutely valid, route may be taken. 243 3.6 Multicasting 245 In order to reduce unnecessary load on those hosts which are not 246 listening to RIP-2 packets, an IP multicast address will be used for 247 periodic broadcasts. The IP multicast address is 224.0.0.9. Note that 248 IGMP is not needed since these are inter-router messages which are not 249 forwarded. 251 In order to maintain backwards compatibility, the use of the 252 multicast address will be configurable, as described in section 4.1. If 253 multicasting is used, it should be used on all interfaces which support 254 it. 256 4. Compatibility 258 RFC 1058 showed considerable forethought in its specification of 259 the handling of version numbers. It specifies that RIP packets of 260 version 0 are to be discarded, that RIP packets of version 1 are 261 to be discarded if any Must Be Zero (MBZ) field is non-zero, and that 262 RIP packets of any version greater than 1 should not be discarded 263 simply because an MBZ field contains a value other than zero. This 264 means that the new version of RIP is totally backwards compatible 265 with existing RIP implementations which adhere to this part of the 266 specification. 268 4.1 Compatibility Switch 270 A compatibility switch is necessary for three reasons. First, there 271 are implementations of RIP-1 in the field which do not follow RFC 272 1058 as described above. Second, the use of multicasting would 273 prevent RIP-1 systems from receiving RIP-2 updates (which may 274 be a desired feature in some cases). Third, the route subsumption 275 rules (see section 3.4) differ for RIP-1 and RIP-2 in their handling 276 of subnet routes. 278 The switch has three settings: RIP-1, in which only RIP-1 packets 279 are sent; RIP-1 compatibility, in which RIP-2 packets are broadcast 280 using RIP-1 subsumption rules; and RIP-2, in which RIP-2 packets are 281 multicast. The recommended default for this switch is RIP-1 compatibility. 283 4.2 Authentication 285 Since an authentication entry is marked with an Address Family 286 Identifier of 0xFFFF, a RIP-1 system would ignore this entry since 287 it would belong to an address family other than IP. It should 288 be noted, therefore, that use of authentication will not prevent 289 RIP-1 systems from seeing RIP-2 packets. If desired, this may 290 be done using multicasting, as described in sections 3.6 and 4.1. 292 4.3 Larger Infinity 294 While on the subject of compatibility, there is one item which people 295 have requested: increasing infinity. The primary reason that this 296 cannot be done is that it would violate backwards compatibility. A 297 larger infinity would obviously confuse older versions of rip. At 298 best, they would ignore the route as they would ignore a metric of 299 16. There was also a proposal to make the Metric a single byte and reuse 300 the high three bytes, but this would break any implementations which 301 treat the metric as a long. 303 4.4 Addressless Links 305 As in RIP-1, addressless links will not be supported by RIP-2. 307 5. Security Considerations 309 The basic RIP protocol is not a secure protocol. To bring RIP-2 310 in line with more modern routing protocols, an extensible authentication 311 mechanism has been incorporated into the protocol enhancements. This 312 mechanism is described in sections 3.1 and 4.2. 314 Appendix A 316 This is a simple example of the use of the next hop field in a rip entry. 318 ----- ----- ----- ----- ----- ----- 319 |IR1| |IR2| |IR3| |XR1| |XR2| |XR3| 320 --+-- --+-- --+-- --+-- --+-- --+-- 321 | | | | | | 322 --+-------+-------+---------------+-------+-------+-- 323 <-------------RIP-2-------------> 325 Assume that IR1, IR2, and IR3 are all "internal" routers which are 326 under one administration (e.g. a campus) which has elected to use 327 RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under 328 separate administration (e.g. a regional network, of which the campus 329 is a member) and are using some other routing protocol (e.g. OSPF). 330 XR1, XR2, and XR3 exchange routing information among themselves such 331 that they know that the best routes to networks N1 and N2 are via 332 XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By 333 setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for 334 N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for 335 routing to occur without additional hops through XR1. Without the 336 Next Hop (for example, if RIP-1 were used) it would be necessary for 337 XR2 and XR3 to also participate in the RIP-2 protocol to eliminate 338 extra hops. 340 Appendix B 342 Route subsumption is basic to IP routing. The idea is to reduce the 343 amount of information other routers need to know in order to route 344 packets correctly. Here are generic and specific examples. 346 Consider the subnets A.B.C.0 and A.B.D.0, where D = C + 1. It would 347 only be necessary to advertise A.B.C.0 with a subnet mask one bit 348 shorter. 350 Consider the following specific example: 352 Address Mask Next hop 353 ---------------------------------------- 354 191.154.88.0 255.255.255.0 191.154.3.8 Subnet route 1 355 191.154.89.0 255.255.255.0 191.154.3.8 Subnet route 2 356 ---------------------------------------- 357 191.154.88.0 255.255.254.0 191.154.3.8 Advertised route 359 References 361 [1] Hedrick, C., Routing Information Protocol, Request For Comments 362 (RFC) 1058, Rutgers University, June 1988. 364 [2] Malkin, G., and F. Baker, draft-ietf-ripv2-mibext-01.txt, 365 Xylogics, ACC, May 8, 1992. 367 Author's Address 369 Gary Scott Malkin 370 Xylogics, Inc. 371 53 Third Avenue 372 Burlington, MA 01803 374 Phone: (617) 272-8140 375 EMail: gmalkin@Xylogics.COM