INTERNET-DRAFT Massimo Torre, Ph.D. Document: draft-massimo-rip-ripv2-00.txt Expires: February 2002 RIP version 2 Status of this Memo: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at . The list of Internet-Draft Shadow Directories can be accessed at . This draft must be intended as an individual submission to the "RIP" working group of the IETF. Table of Contents 1. Abstract 2. Introduction 3. The Problem 4. Configuration scheme 5. Results 6. Considerations 7. Supporting documentation 8. Changing the current RFC 9. Summary 10. References 11. Disclaimer 12. Author's address 1. Abstract This draft is intended to be a proposal for updating the current "RIP version 2" RFC [1]. This necessity is due to a difference of behaviour between the RIP protocol as described in [1] and the RIP protocol as implemented by many vendors. If all the vendors apply the same rule, no problem arises. But, on the contrary, serious problems of interoperability can occur. With some little changes in the text, this draft can be used as the new "RIP version 2" RFC. People just interested in the implementing protocols may simply go to paragraph 8 (Changing the current RFC) and skip all the others. The purpose of all the other paragraphs is to support the idea of changing the RFC. 2. Introduction As I noticed the difference, I wrote the Internet draft [2] in order to receive suggestions; indeed I received several e-mails by people working on RIP; many of them agreed with me on the difference and some suggested me to propose an updated version of the RFC. 3. The Problem Let's imagine this simple configuration: two routers directly connected to each other independently of the medium, i.e. point to point connection through ethernet, modem, or whatever else. In the process of sending a RIP update message from the sending router (let's call "A" from now on) to the receiving router (let's call "B"), the metric inside the RIP packet is already updated to the final value, while the standard specifies that the final value of the metric must be set by B (see page paragraph 3.9.2 of [1]). For example, if the routing table of A contains a route for a certain destination, and the metric for this route is 1 (hop count metric), what should happen according to the standard is that the number 1 is transmitted inside the RIP packet to B, and B adds 1 (the hop count for the direct connection) during the updating process of its routing table. Instead, what really happens, is that the metric inside the RIP packet is already set to 2 (=1+1) by A, and B has to do nothing other than the normal check of the message. 4. Configuration scheme The above configuration example is very simple; however I'll go in details through the description of the scheme I used to discover the difference between the standard and the real behaviour of routers. The following picture shows the configuration scheme used. +---+ |PC | +---+ |1.2 Network Prefix: 192.168 1.0/24 | +-------------+ | |1.1 +-------+ +-------+ +-------+ | |2.1 2.2| |3.1 3.2| | | R1 |-------------| R2 |------------| R3 | | | 2.0/30 | | 3.0/30 | | | +-------+ +-------+ | +-------+ | | +---+ |SP | +---+ R1, R2, R3 are identical routers implementing RIP v.2; SP stands for "Sniffer Pro", the protocol analyzer by Network Associates. It was mounted on a normal PC connected to the network through a hub. The "experiment" has been repeated with routers of different vendors (Cisco, ACC, etc.). 5. Results The following is the situation once the network reaches stability. Table 1 shows the metrics of the routes towards the LAN 1.0/24 contained in the routing tables of all the routers. Router | Metric | Source -------+--------+------- R1 | 0 | LOC -------|--------|------- R2 | 1 | RIP -------|--------|------- R3 | 2 | RIP -------+--------+------- Table 1 Table 2 shows the summary of the metrics contained in each RIP packet sent every 30 seconds (by default) and captured by the SN. Each packet has the following IP addresses: Destination Address: 224.0.0.9 (multicast RIP address) Source address: 192.168.3.1 (R2 interface towards R3) Route | Metric -------+------- 1.0/24 | 2 -------|------- 2.0/30 | 1 -------|------- 3.0/30 | 1 -------+------- Table 2 The following is the sniffer trace of each packet (only RIP part): RIP: ------ RIP Header ----- RIP: RIP: Command = 2 (Response) RIP: Version = 2 RIP: Unused = 0 RIP: RIP: Routing data frame 1 RIP: Address family identifier = 2 (IP) RIP: Route Tag = 512 RIP: IP Address = [192.168.1.0] RIP: Subnet Mask = [255.255.255.0] RIP: Next Hop = [0.0.0.0] (routing via originator) RIP: Metric = 2 RIP: RIP: Routing data frame 2 RIP: Address family identifier = 2 (IP) RIP: Route Tag = 0 RIP: IP Address = [192.168.2.0] RIP: Subnet Mask = [255.255.255.252] RIP: Next Hop = [0.0.0.0] (routing via originator) RIP: Metric = 1 RIP: RIP: Routing data frame 3 RIP: Address family identifier = 2 (IP) RIP: Route Tag = 0 RIP: IP Address = [192.168.3.0] RIP: Subnet Mask = [255.255.255.252] RIP: Next Hop = [0.0.0.0] (routing via originator) RIP: Metric = 1 RIP: 6. Considerations The RIP implementation results, clearly show the difference from the RIP standard description. For example, as we can see from table 1, the metric for the LAN inside the routing table of R2 is 1 and, according to the RFC, this value should be transmitted to R3. Instead, the actual value transmitted to R3 is 2, as we can see from table 2 (first item) and the sniffer trace (Routing data frame 1). 7. Supporting documentation Everyone can repeat the simple "experiment" described above and draw one's own conclusions. However, there are several documents supporting the implementation behaviour just mentioned. For example, we can consider [3] at page 373: "Before sending an update, a router increments its metric for routes to each subnet by 1." 8. Changing the current RFC There is no need to completely rewrite the current RFC. According to page 12 of [4], I would suggest a simple RFC that updates [1]. This simple RFC should state as follows: "RIP v.2 is full described in RFC 2453. The formula: (paragraph 3.9.2, "Response Messages", page 27) must be applied in the output processing, while the input one must take the exact metric value inside the RIP packet and put it in the routing table (of course, all the other checks in the input processing, remain unchanged)." 9. Summary This internet draft has pointed out one difference between the RIP protocol as described by RFC 2453, and the one implemented by many vendors. This difference could causes serious problems of interoperability as said in the abstract. Simply by changing the current RFC as depicted in the previous paragraph, the problem is solved. 10. References [1] G. Malkin, "RIP Version 2", RFC 2453 also STD 56, November 1998. [2] M. Torre, "Comments on RFC 2453", Internet Draft, expiring date February 2002. [3] W. Odom, "Cisco CCNA Exame #640-507 Certification Guide", Cisco Press, Indianapolis, USA, 2000. [4] J. Postel, J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. 11. Disclaimer The opinions expressed in this draft are solely the author's. The worldwide company which I work for has not been mentioned. 12. Author's address Massimo Torre, Ph.D. Rome, Italy Fax: +39 06 233208654 E.Mail: maxtow@altavista.net