skip to content

Why does RIPv2 send its periodic updates to the multicast address 224.0.0.9, when RIPv1 broadcast them to every host on the segment?

level: juniorimportance: should knowfreq 22%

answer

  1. who else receives a broadcast
  2. hosts that do not run RIP
  3. a group only RIP routers join
  4. never forwarded, so no IGMP
  5. a per-interface compatibility switch

basics

~20 s

A RIPv1 broadcast reaches every station on the segment, and each must take it in and discard it. RIPv2 sends to 224.0.0.9, a group only RIP routers join, so other hosts can filter it out; a per-interface switch keeps broadcast for RIPv1 neighbours.

solid answer

~50 s

RIPv1 sends its periodic and triggered updates as broadcasts, so every station on the segment, including servers and workstations that run no routing protocol, receives each one into its IP stack only to find nothing on UDP port 520 and drop it. RFC 2453 sends RIPv2 updates to the multicast group `224.0.0.9` to reduce that load on hosts that are not listening. On Ethernet the group maps to a multicast MAC address, so an interface that has not joined it can discard the frame before IP sees it. No IGMP is needed, because these messages go only between neighbouring routers and are never forwarded. On NBMA networks RIPv2 may unicast instead. A RIPv1 router does not listen to the group, so RFC 2453 defines a per-interface send switch whose `RIP-1 compatibility` setting broadcasts RIPv2 messages for mixed segments.

go deeper

for a junior

Recall the contrast: RIPv1 broadcasts its updates, RIPv2 multicasts them to 224.0.0.9, and both use UDP port 520. The point is to spare hosts that do not run RIP.

for a middle

Explain why a broadcast costs every host on the link, how the multicast MAC lets non-members filter early, why no IGMP is needed, and when RIPv2 falls back to unicast.

for a senior

Be ready to run a mixed RIPv1 and RIPv2 segment: which send and receive settings each interface needs, and why RIPv1 routers that ignore RIPv2's masks need care.

for a principal

Treat multicast as an efficiency choice, not a security boundary, and decide where routing protocols should run at all on segments shared with untrusted hosts.

## Broadcast in RIPv1 **RIP** (Routing Information Protocol) routers exchange routing tables over **UDP port 520**. **RIPv1** (RFC 1058) delivers its regular and triggered updates as **broadcasts** on every directly connected network that supports broadcasting. A broadcast is addressed to every station on the link, so the update is received by: - the other RIP routers, which need it; - every host, printer and server on the segment, which does not. Each of those hosts has to accept the frame, pass it up to IP and UDP, find that no process is bound to port 520 and discard it. On a busy segment with a large routing table that is wasted work on every non-router, repeated for as long as RIP runs. ## Multicast in RIPv2 **RIPv2** (RFC 2453, section 4.5) replaces the broadcast with the IP multicast address **`224.0.0.9`**, and gives the reason directly: to reduce unnecessary load on hosts that are not listening to RIPv2 messages. 1. A RIPv2 router joins the group `224.0.0.9` on its RIP interfaces and sends its updates to it. 2. On Ethernet, RFC 1112's mapping places the low-order 23 bits of the group address into the multicast MAC prefix `01-00-5E-00-00-00`, giving `01-00-5E-00-00-09`. 3. A host that has not joined the group can drop that frame at its interface instead of processing it up the stack. Two details matter. **No IGMP is required**: RFC 2453 notes these are inter-router messages that are not forwarded, so there is nothing for a multicast router to learn. And on **NBMA** networks, where multicast may not reach every neighbour, RIPv2 may use **unicast**; a response that does arrive addressed to `224.0.0.9` should still be accepted. ## Mixing RIPv1 and RIPv2 on one segment A RIPv1 router does not listen to `224.0.0.9`, so a RIPv2 router that only multicasts is invisible to it. RFC 2453 section 5.1 therefore requires a **compatibility switch**, configurable per interface: | Send setting | What is sent | Who can hear it | |---|---|---| | `RIP-1` | RIP-1 messages only | RIPv1 routers, and RIPv2 routers set to accept RIP-1 | | `RIP-1 compatibility` | RIP-2 messages, **broadcast** | RIPv1 routers (which ignore the new fields) and RIPv2 routers | | `RIP-2` | RIP-2 messages, **multicast** to `224.0.0.9` | RIPv2 routers | | `none` | nothing | nobody | RFC 2453 recommends that the default be `RIP-1` or `RIP-2`, **not** `RIP-1 compatibility`, citing potential problems on some topologies: RIPv1 routers ignore the masks in those messages and apply their own assumptions. Compatibility mode should be used only when its consequences are understood. A matching **receive switch** decides whether an interface accepts RIP-1 only, RIP-2 only, both, or none. ## What multicast does not do - **It is not security.** Any host can join `224.0.0.9` and read the updates, and any host can send to it. Authenticating updates is a separate RIPv2 feature, carried in the first route entry. - **It does not reduce the routers' own work.** Every RIP router on the segment still receives and processes every update. - **It does not change the update contents.** The same routes, metrics and fields go out either way; only the destination address changes. - **It does not change the port.** RIPv1 and RIPv2 both use UDP port 520. ## Summary | | RIPv1 | RIPv2 | |---|---|---| | Destination of periodic updates | broadcast | `224.0.0.9` (unicast allowed on NBMA) | | Group membership signalling | none | none: no IGMP needed | | Hosts that are not routers | must process and drop each update | can filter the frame at the interface | | Reaching RIPv1 neighbours | n/a | `RIP-1` or `RIP-1 compatibility` send setting | The change is small on the wire and saves work for every host on a shared segment, which is why it is a standard interview contrast between the two versions.

  • Does sending RIPv2 updates to 224.0.0.9 stop an attacker on the segment from injecting routes?
    No. Multicast only limits which interfaces bother to process the update; any host can join the group or send to it. Protection against forged updates comes from RIPv2 authentication, ideally the cryptographic kind from RFC 4822, or from not running RIP on segments where untrusted hosts live.
  • Why does RFC 2453 recommend against RIP-1 compatibility as the default send setting?
    In that mode RIPv2 messages, with their subnet masks, are broadcast to RIPv1 routers that ignore the masks and infer their own, and RFC 2453 cites potential problems on some topologies; its section 4.3 adds rules on what may be advertised where RIPv1 routers listen. It says to use the mode only when the administrator understands all of its consequences.

saying these in an interview costs you the question

  • RIPv2 multicast keeps the routing updates confidential from other hosts.
  • Routers must send IGMP reports before they can receive RIPv2 updates.
  • RIPv2 updates to 224.0.0.9 are forwarded to RIP routers on other subnets.
  • RIPv2 moved to a different UDP port when it switched to multicast.
  • A RIPv1 router hears RIPv2 multicasts because it listens to all multicast groups.