RIP Version 2 - Carrying Additional Information
obsoleted by
- rfc-2453 — RIP Version 2
obsoletes
- rfc-1388 — RIP Version 2 Carrying Additional Information
updates
- rfc-1058 — Routing Information Protocol
Extracted elements (23)
Addressless links are not supported by RIP-2, consistent with the RIP-1 design. This limitation is inherited rather than introduced by the v2 extensions.
Authentication is implemented by repurposing the first route entry slot (AFI=0xFFFF) rather than a dedicated header field, because the single 2-octet field available in the message header is insufficient for any reasonable authentication scheme. This approach costs one route entry slot (reducing max routes from 25 to 24).
Multicast address 224.0.0.9 is used for RIP-2 periodic broadcasts to avoid unnecessary processing load on hosts that are not RIP-2 speakers. IGMP is not required because RIP-2 messages are inter-router and not forwarded.
The infinity metric (16) cannot be increased in RIP-2 because doing so would break backwards compatibility: older RIP-1 implementations would be confused by a larger infinity value, and at best would ignore routes with metrics >= 16. A proposal to shrink the metric to one octet was also rejected as it would break implementations treating the metric as a 4-octet entity.
The Next Hop field is designed to eliminate sub-optimal routing when RIP is not deployed on all routers in a network. It allows a single RIP-2 router (e.g., XR1) to advertise routes on behalf of other routers (XR2, XR3) with the correct next hop, avoiding extra hops through the advertising router.
A RIP-1 system will ignore the authentication entry because its AFI (0xFFFF) belongs to an address family other than IP. Therefore, authentication alone will not prevent RIP-1 systems from receiving RIP-2 messages; multicasting must be used to achieve that effect.
RIP-2 is backwards compatible with RFC 1058-compliant RIP-1 implementations because RFC 1058 specifies that messages of version > 1 must not be discarded solely because a Must-Be-Zero field is non-zero. Non-compliant RIP-1 implementations may require the compatibility switch to be set to RIP-1 compatibility (broadcast) mode.
A per-interface compatibility switch MUST be configurable with four settings: RIP-1 (broadcast RIP-1 only), RIP-1 compatibility (broadcast RIP-2), RIP-2 (multicast RIP-2), and 'none' (disable sending). The recommended default is RIP-1 compatibility.
Currently, the only defined Authentication Type is simple password (type 2). The 16-octet password field must be left-justified and padded on the right with null bytes (0x00) if the password is under 16 octets.
If a RIP-2 router receives a RIP-1 Request, it SHOULD respond with a RIP-1 Response. If configured to send only RIP-2 messages, it should not respond to a RIP-1 Request.
If a router is not configured to authenticate RIP-2 messages, authenticated RIP-2 messages SHALL be discarded. If configured for authentication, unauthenticated RIP-2 messages and those failing authentication SHALL be discarded. For maximum security, RIP-1 messages SHOULD be ignored when authentication is in use.
If the received Next Hop address is not directly reachable on the logical subnet over which the advertisement is made, it MUST be treated as 0.0.0.0.
On interfaces where RIP-1 routers may hear RIP-2 entries: (1) information internal to one network must never be advertised into another network; (2) more-specific subnet information may not be advertised where RIP-1 routers would treat it as a host route; (3) supernet routes must not be advertised where they could be misinterpreted by RIP-1 routers.
RIP-2 uses IP multicast address 224.0.0.9 for periodic broadcasts to reduce unnecessary load on hosts not listening to RIP-2 messages. If multicasting is used, it SHOULD be used on all interfaces which support it.
The Route Tag must be preserved and re-advertised with a route. Routers supporting protocols other than RIP should be configurable to set the Route Tag for routes imported from different sources (e.g., to the Autonomous System number from BGP/EGP).
The Version field MUST be set to 2 for RIP messages that use authentication or carry information in any newly defined fields (Route Tag, Subnet Mask, Next Hop).
Next Hop (4-byte field per route entry): the immediate next-hop IP address for packets to the destination. A value of 0.0.0.0 means route via the originator of the RIP advertisement. This is an advisory field; if ignored, a sub-optimal but valid route may be taken.
Route Tag (2-byte field per route entry): an attribute that must be preserved and re-advertised with a route, intended to distinguish internal RIP routes from external routes imported from EGP or another IGP such as BGP.
Subnet Mask (4-byte field per route entry): the subnet mask applied to the IP address to yield the non-host portion. A value of zero means no subnet mask is included for that entry.
For maximum security when authentication is enabled, RIP-1 messages should be ignored (via the compatibility switch set to RIP-2 multicast mode), since RIP-1 messages carry no authentication and could be used to inject false routing information.
The basic RIP protocol is not secure. RIP-2 adds an extensible authentication mechanism to address this, currently supporting simple plaintext password authentication (type 2). The authentication entry uses 16 octets of plaintext password, which provides minimal security and is vulnerable to eavesdropping.
Authentication entry: when the AFI of the first route entry is 0xFFFF, the entry holds authentication data — AFI (2B, 0xFFFF), Authentication Type (2B), and Authentication (16B). This consumes one entry slot, reducing maximum route entries to 24.
RIP version 2 message format: 4-octet header (Command 1B, Version 1B, unused 2B) followed by 1–25 route entries of 20 octets each, containing AFI (2B), Route Tag (2B), IP Address (4B), Subnet Mask (4B), Next Hop (4B), and Metric (4B). All fields are big-endian.