RIP Version 2 Carrying Additional Information
RFC 1388
Document | Type |
RFC - Proposed Standard
(January 1993; No errata)
Obsoleted by RFC 1723
Updates RFC 1058
Was draft-malkin-rip (ripv2 WG)
|
|
---|---|---|---|
Author | Gary Malkin | ||
Last updated | 2013-03-02 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1388 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group G. Malkin Request for Comments: 1388 Xylogics, Inc. Updates: RFC 1058 January 1993 RIP Version 2 Carrying Additional Information Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document specifies an extension of the Routing Information Protocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP packets and to add a measure of security. A companion document will define the SNMP MIB objects for RIP-2 [2]. Acknowledgements I would like to thank the following for their contributions to this document: Fred Baker, Noel Chiappa and Vince Fuller. This memo is a product of the RIP-2 Working Group of the Internet Engineering Task Force (IETF). Table of Contents 1. Justification . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 2 3.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 3 3.2 Routing Domain . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.5 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.6 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 5 4.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 6 4.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Malkin [Page 1] RFC 1388 RIP Version 2 January 1993 Security Considerations . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Justification With the advent of OSPF and IS-IS, there are those who believe that RIP is obsolete. While it is true that the newer IGP routing protocols are far superior to RIP, RIP does have some advantages. Primarily, in a small network, RIP has very little overhead in terms of bandwidth used and configuration and management time. RIP is also very easy to implement, especially in relation to the newer IGPs. Additionally, there are many, many more RIP implementations in the field than OSPF and IS-IS combined. It is likely to remain that way for some years yet. Given that RIP will be useful in many environments for some period of time, it is reasonable to increase RIP's usefulness. This is especially true since the gain is far greater than the expense of the change. 2. Current RIP The current RIP packet contains the minimal amount of information necessary for routers to route packets through a network. It also contains a large amount of unused space, owing to its origins. The current RIP protocol does not consider autonomous systems and IGP/EGP interactions, subnetting, and authentication since implementations of these postdate RIP. The lack of subnet masks is a particularly serious problem for routers since they need a subnet mask to know how to determine a route. If a RIP route is a network route (all non-network bits 0), the subnet mask equals the network mask. However, if some of the non-network bits are set, the router cannot determine the subnet mask. Worse still, the router cannot determine if the RIP route is a subnet route or a host route. Currently, some routers simply choose the subnet mask of the interface over which the route was learned and determine the route type from that. 3. Protocol Extensions This document does not change the RIP protocol per se. Rather, it provides extensions to the datagram format which allows routers to share important additional information. Malkin [Page 2] RFC 1388 RIP Version 2 January 1993 The new RIP datagram format is: 0 1 2 3 3 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 1Show full document text