RIP Version 2 Carrying Additional Information
obsoleted by
- rfc-1723 — RIP Version 2 - Carrying Additional Information
updates
- rfc-1058 — Routing Information Protocol
Extracted elements (24)
Authentication is implemented by consuming an entire route-entry slot (16 bytes) rather than fitting into the 2-byte header field, because any reasonable authentication scheme requires more than two bytes. This limits authenticated packets to a maximum of 24 route entries.
Increasing the infinity metric beyond 15 was explicitly rejected because it would break backwards compatibility: older RIP implementations would be confused by a metric of 16 or higher, and repurposing the high three bytes of the Metric field would break implementations treating the metric as a 32-bit integer.
Multicast (224.0.0.9) is made configurable rather than mandatory to maintain backwards compatibility with RIP-1 deployments that do not support or listen to multicast; the default mode (RIP-1 compatibility) uses broadcast instead.
The Next Hop field is classified as 'advisory': if the provided information is ignored, a possibly sub-optimal but absolutely valid route may still be taken. Its primary purpose is to eliminate extra hops when RIP is not running on all routers on a network.
The Routing Domain field enables multiple independent RIP 'clouds' to coexist on the same physical wire, giving administrators the ability to run parallel RIP instances for simple policy implementation without requiring separate physical infrastructure.
A RIP-1 system will silently ignore an authentication entry because its AFI (0xFFFF) corresponds to an address family other than IP. Consequently, authentication alone does not prevent RIP-1 systems from receiving and processing the route entries in a RIP-2 packet; multicasting is required to achieve that separation.
Addressless links are not supported by RIP-2, consistent with RIP-1.
RFC 1058 specifies that RIP packets of version 0 are discarded, version 1 packets are discarded if any Must-Be-Zero field is non-zero, and packets of any version greater than 1 should not be discarded solely because an MBZ field is non-zero. RIP-2 is therefore fully backwards compatible with RFC 1058-compliant RIP-1 implementations.
A router operating within one routing domain or set of routing domains MUST ignore RIP packets belonging to another routing domain.
Any RIP system that receives a RIP entry containing a non-zero Route Tag value MUST re-advertise that value. Routes with no Route Tag value MUST advertise an RT of zero.
If multicasting is used, it SHOULD be used on all interfaces that support it.
If the Address Family Identifier of the first entry is 0xFFFF, that entry is treated as an authentication entry. If authentication is not in use, no entry in the packet should have an AFI of 0xFFFF.
On an interface where a RIP-1 router may operate on RIP-2 routing entries: (1) information internal to one network MUST NOT be advertised into another network, and (2) information about a more specific subnet MUST NOT be advertised where RIP-1 routers would consider it a host route.
A compatibility switch with three settings controls interoperability: 'RIP-1' sends only RIP-1 packets; 'RIP-1 compatibility' broadcasts RIP-2 packets (default); 'RIP-2' multicasts RIP-2 packets. The recommended default is RIP-1 compatibility.
RIP-2 uses the IP multicast address 224.0.0.9 for periodic broadcasts to reduce unnecessary load on hosts not listening to RIP-2. IGMP is not required since these are inter-router messages that are not forwarded.
The Next Hop field is a 4-byte per-entry value specifying the immediate next-hop IP address for packets to the destination. A value of 0.0.0.0 means routing should be via the originator of the RIP advertisement. The specified next hop must be directly reachable on the logical subnet over which the advertisement is made.
The only defined Authentication Type in this version is simple password (type 2), carrying a plain-text password of up to 16 bytes in the authentication field.
The Route Tag (RT) field is a 2-byte per-entry field intended to carry EGP/BGP Autonomous System numbers for route redistribution. Any RIP system that receives a route entry with a non-zero RT value must re-advertise that value; routes with no RT value must advertise RT = 0.
The Routing Domain (RD) field is a 2-byte value in the packet header that identifies the routing process to which the update belongs, allowing multiple independent RIP instances to coexist on the same physical wire. RD 0 is the default routing domain.
The Subnet Mask field is a 4-byte per-entry value that is ANDed with the IP Address to yield the non-host portion of the address. A value of 0.0.0.0 indicates no subnet mask is included for that entry.
The Version field in the RIP-2 header MUST be set to 2 for any datagram that uses authentication or carries information in any of the newly defined fields.
The basic RIP protocol is not a secure protocol. RIP-2 addresses this by incorporating an extensible authentication mechanism using the first route-entry slot in the packet; the only currently defined method is simple plain-text password, which provides minimal security.
Authentication is encoded by setting the Address Family Identifier of the first route entry to 0xFFFF; the subsequent 2 bytes carry the Authentication Type and the remaining 16 bytes carry the authentication data (e.g., plain-text password, left-justified and null-padded). This consumes one full route-entry slot, leaving at most 24 route entries in an authenticated packet.
The RIP-2 datagram adds a 2-byte Routing Domain field in the header (replacing Must-Be-Zero), and extends each route entry to include Route Tag (2 bytes), Subnet Mask (4 bytes), and Next Hop (4 bytes) fields, all in big-endian order.