RIP Version 2
obsoletes
- rfc-1723 — RIP Version 2 - Carrying Additional Information
updated by
- rfc-4822 — RIPv2 Cryptographic Authentication
also
- std-56
Extracted elements (27)
Authentication in RIP-2 consumes an entire 20-octet RTE slot (AFI = 0xFFFF) because the RIP message header provides only 2 octets for version-specific use—insufficient for any reasonable authentication scheme. This design limits authenticated messages to at most 24 route entries.
Infinity is set to 16 (one more than the maximum usable metric of 15) to minimize the time spent counting to infinity when a network becomes unreachable. The value is intentionally small because the protocol is considered impractical for networks with a diameter larger than 15 hops, and faster convergence to infinity outweighs the benefit of a larger maximum network size.
Split horizon with poisoned reverse (advertising reverse routes at metric 16) breaks two-router loops immediately but increases update message size, especially on campus backbones where many subnets would be advertised back at infinity. Simple split horizon uses less bandwidth but requires a timeout to clear erroneous routes. Implementations may provide a knob to choose between them.
Implementations SHOULD provide a per-interface compatibility switch with four settings: RIP-1 (broadcast RIP-1 only), RIP-1 compatibility (broadcast RIP-2), RIP-2 (multicast RIP-2), and none. The recommended default is RIP-1 or RIP-2; RIP-1 compatibility SHOULD only be used when all consequences are understood by the administrator. A receive control switch for filtering accepted versions is also recommended.
RIP-1 specifies that version-0 messages must be discarded, version-1 messages must be discarded if any Must-Be-Zero field is non-zero, and messages of version greater than 1 must not be discarded solely because an MBZ field is non-zero. RIP-2 is fully backward-compatible with RIP-1 implementations that respect this versioning rule.
A received Response MUST be ignored if it did not arrive from UDP port 520. The source IPv4 address MUST be on a directly-connected network. Datagrams originating from the router's own address MUST be discarded to prevent processing self-broadcast output as new routing input.
All RIP implementations MUST implement triggered updates for deleted routes and MAY implement them for new or changed routes. After a triggered update is sent, a timer MUST be set for a random interval of 1–5 seconds; changes that occur before it expires are batched into a single update when it fires. A triggered update MUST be suppressed if a regular update is already due.
All RIP implementations MUST use split horizon, and SHOULD also use split horizon with poisoned reverse (advertising reverse routes with metric 16). A configuration option to disable poisoned reverse is permitted. Implementors may alternatively implement simple split horizon (omitting reverse routes) or configurable hybrid schemes.
For a whole-table Request, split horizon processing MUST be applied before sending the Response. For a specific-entry Request, split horizon processing MUST NOT be applied; entries are returned exactly as they appear in the routing table.
On interfaces where RIP-1 routers may be present, RIP-2 MUST NOT advertise information internal to one network into another network, MUST NOT advertise more-specific subnet routes where RIP-1 would treat them as host routes, and MUST NOT advertise supernet routes where RIP-1 routers could misinterpret them.
RIP-2 metric processing requires: metric = MIN(metric + cost_of_incoming_network, 16). Routes with metric greater than infinity received in an update MUST be logged and the entry ignored. Routes with invalid destination addresses (net 0, net 127, or non-unicast) MUST be silently dropped.
RIP implementations MUST send unsolicited Response messages every 30 seconds and MUST prevent timer synchronization across routers, either by using a clock unaffected by system load or by randomizing the 30-second interval by ±0–5 seconds each time it is set.
When generating a Response to a Request, the Response version SHOULD match the Request version. If a RIP-2 router is configured to send only RIP-2 messages, it MUST NOT respond to a RIP-1 Request.
When using RIP-1, subnet routes MUST NOT be sent to routers outside the network of which the subnet is a part, because those routers cannot determine the subnet mask and would misinterpret the address. Border routers MUST advertise only a single aggregate entry for the network as a whole to neighbors on other networks.
A single RIP Response message may contain between 1 and 25 Route Entries (RTEs). When authentication is present the limit drops to 24 RTEs. There is no defined upper limit on the number of datagrams comprising a complete routing table response.
RIP-2 uses the IP multicast address 224.0.0.9 for periodic routing updates to reduce load on non-RIP-2 hosts. IGMP is not required because these are inter-router messages that are not forwarded. On NBMA networks, unicast addressing may be used instead.
RIP operates over UDP on port 520. Unsolicited routing updates are sent with both source and destination port equal to 520; responses to specific queries are sent to the port from which the request originated.
RIP uses a maximum valid metric of 15 hops; a metric of 16 represents infinity (unreachability). The infinity value was chosen as small as feasible to bound the duration of counting-to-infinity convergence problems.
The Next Hop field (4 octets) specifies the immediate next-hop IP address for packets toward the destination. A value of 0.0.0.0 means route via the advertisement originator. The field is advisory: if not directly reachable, it must be treated as 0.0.0.0. Its purpose is to eliminate unnecessary extra hops when RIP is not running on all routers in a network.
The Route Tag field (2 octets in the RIP-2 RTE) is an attribute that must be preserved and re-advertised with the route. Its primary purpose is to distinguish internal RIP routes from routes imported from EGP, BGP, or another IGP; it may be set to the originating Autonomous System number.
The Subnet Mask field (4 octets) in the RIP-2 RTE specifies the mask applied to the IP address to yield the non-host portion. A value of zero means no subnet mask was included. This field eliminates the subnet/host ambiguity inherent in RIP-1.
The only authentication type defined in this document is type 2—a 16-octet plain-text password carried in the clear. This provides minimal security: the password is easily observable by any party that can capture RIP packets. A companion document defines cryptographic authentication improvements for RIP-2.
Each route entry cycles through three timer-driven states. Active: route is valid; the 180-second timeout resets on each received update. Expired: timeout fires, metric set to 16 (infinity), 120-second garbage-collection timer starts, triggered update signaled. Deleted: garbage-collection timer expires and route is removed from the table. A new route received during garbage collection cancels the timer and replaces the entry.
A RIP-1 Route Entry is 20 octets: a 2-octet Address Family Identifier (AFI), a 2-octet must-be-zero field, a 4-octet IPv4 address, two 4-octet must-be-zero fields, and a 4-octet metric (1–16). AF_INET is AFI value 2.
A RIP-2 Route Entry is 20 octets: a 2-octet AFI, a 2-octet Route Tag, a 4-octet IP address, a 4-octet Subnet Mask, a 4-octet Next Hop address, and a 4-octet metric. Version must be set to 2 when any of the new fields carry information.
RIP-2 authentication occupies the first Route Entry slot: AFI is set to 0xFFFF, followed by a 2-octet Authentication Type and 16 octets of authentication data. Authentication type 2 is simple plaintext password; if under 16 octets, the password is left-justified and null-padded on the right. When authentication is present, at most 24 RTEs remain in the message.
The RIP packet header contains a 1-octet command field, a 1-octet version field, and a 2-octet must-be-zero field, followed by between 1 and 25 Route Entries of 20 octets each. All multi-octet integers are in network byte order (big-endian).