RIPng (RIP Next Generation) is the IPv6 adaptation of RIP, defined in RFC 2080. It’s a distance-vector protocol that keeps RIP’s core simplicity — hop count as the metric, a 15-hop maximum, periodic updates — while adapting the protocol’s mechanics for IPv6 addressing. This guide covers how RIPng differs from RIPv2, how to configure it, how to propagate a default IPv6 route through it, and a real quirk in how its hop count is reported that’s worth understanding rather than memorizing blindly.
[See Infographic: RIPng vs RIPv2 Configuration Model]
How RIPng Differs from RIPv2
RIPng shares RIP’s fundamental distance-vector design, but several mechanics change for IPv6:
- Transport and delivery. RIPng uses UDP port 521 and multicasts updates to
FF02::9, replacing RIPv2’s UDP port 520 and its 224.0.0.9 multicast group. - No
networkcommand. Unlike RIPv2, which enables the protocol on a network-by-network basis usingnetworkstatements underrouter rip, RIPng has no equivalent command. It’s enabled directly on each interface instead. - Authentication. RIPng doesn’t use RIPv2’s built-in MD5 key-chain authentication. Instead, it relies on IPsec to secure its updates — a CCNP-level topic, but worth knowing it exists at the CCNA level.
- Process name. RIPng requires a locally significant process name, created once in global configuration mode and then referenced on every interface where RIPng should run.
| Feature | RIPng | RIPv2 |
|---|---|---|
| Address family | IPv6 | IPv4 |
| Transport | UDP port 521 | UDP port 520 |
| Multicast address | FF02::9 | 224.0.0.9 |
| Enabled via | Per-interface command | Global network command |
| Authentication | IPsec | MD5 key-chain |
| Max hop count | 15 | 15 |
RIPng’s advantages and limitations mirror RIPv2’s: it’s simple to configure for a small network, but its 15-hop ceiling and slow, full-table-broadcast convergence make it unsuitable for anything beyond a lab or a legacy environment. OSPFv3 is the modern replacement in real IPv6 deployments.
Configuring RIPng
Before enabling RIPng on any interface, create the RIPng process in global configuration mode with a locally significant name — this example uses RIPNG_PROC consistently across every router:
Router0(config)# ipv6 unicast-routing
Router0(config)# ipv6 router rip RIPNG_PROCThen enable RIPng on each participating interface individually — this is the step that replaces RIPv2’s network command entirely:
Router0(config)# interface FastEthernet0/0
Router0(config-if)# ipv6 rip RIPNG_PROC enable
Router0(config-if)# exit
Router0(config)# interface FastEthernet0/1
Router0(config-if)# ipv6 rip RIPNG_PROC enable
Router0(config-if)# exitA router with three interfaces participating in RIPng follows the same pattern for each one:
Router1(config)# ipv6 unicast-routing
Router1(config)# ipv6 router rip RIPNG_PROC
Router1(config)# interface FastEthernet0/0
Router1(config-if)# ipv6 rip RIPNG_PROC enable
Router1(config-if)# exit
Router1(config)# interface FastEthernet0/1
Router1(config-if)# ipv6 rip RIPNG_PROC enable
Router1(config-if)# exit
Router1(config)# interface FastEthernet1/0
Router1(config-if)# ipv6 rip RIPNG_PROC enable
Router1(config-if)# exitEvery other router in the topology follows the identical pattern: enable ipv6 unicast-routing, create the process with ipv6 router rip RIPNG_PROC, and enable RIPng on each participating interface with ipv6 rip RIPNG_PROC enable. Using the same process name across every router isn’t strictly required by the protocol — the name is locally significant to each router — but keeping it consistent avoids confusion during configuration and troubleshooting.
[See Infographic: Enabling RIPng Per Interface Instead of Per Network]
Propagating a Default IPv6 Route in RIPng
Propagating a default route through RIPng follows the same underlying logic as RIPv2: configure a static default route, then tell the RIPng process to originate it into its updates. The syntax is IPv6-specific, and the default-information command sits in a different configuration mode than in RIPv2.
Router0(config)# ipv6 route ::/0 2001:DB8::1
Router0(config)# ipv6 router rip RIPNG_PROC
Router0(config-router)# default-information originateThe first line — ipv6 route — is a global configuration mode command, configuring a static IPv6 default route toward the actual next hop (or, alternatively, toward an exit interface on a point-to-point link). The default-information originate command, by contrast, is entered under the RIPng process itself, in router configuration mode, and is what actually triggers RIPng to advertise that static default route to every other router in the RIPng domain — without it, the static default route stays local to Router0.
This mirrors RIPv2’s default-information originate behavior closely, with the practical difference being IPv6 syntax throughout and the fact that RIPng requires the route to be a genuinely specified static entry, since RIPng has no network-based mechanism that could otherwise imply a default route.
[See Infographic: Propagating a Default IPv6 Route Through RIPng]
Verifying the RIPng Configuration
show ipv6 protocols confirms the RIPng process is active and lists which interfaces are participating:
Router0# show ipv6 protocols
IPv6 Routing Protocol is "rip RIPNG_PROC"
Interfaces:
FastEthernet0/0
FastEthernet0/1
Redistribution:
NoneThis output carries noticeably less detail than its IPv4 counterpart, show ip protocols — it confirms the process is running and which interfaces belong to it, but doesn’t show timers or summarization state the way the IPv4 version does.
show ipv6 route rip displays the actual RIPng-learned entries in the routing table:
Router0# show ipv6 route rip
R 2001:DB8:2::/64 [120/2]
via FE80::2, FastEthernet0/0The [120/2] here follows the familiar [administrative-distance/metric] format — 120 is RIPng’s administrative distance, matching RIPv2, and 2 is the hop count metric.
If routes are missing from the routing table, check three things in order: that ipv6 unicast-routing is enabled globally, that RIPng is actually enabled on the expected interfaces (show ipv6 protocols will confirm this), and that link-local addressing is functioning correctly on the interfaces in question, since RIPng’s next-hop resolution depends on link-local addresses the same way any IPv6 dynamic routing protocol does.
Metrics and Hop Count — Including a Real RIPng Quirk
RIPng uses hop count as its metric, capped at 15, exactly like RIPv2. Each router increments the metric by 1 as a route is passed along: if R2 advertises its local network to R1 with metric 1, R1 installs it with metric 1 and re-advertises it to R0 with metric 2, and R0 installs it with metric 2 — two hops away. So far, this is identical to RIPv2.
There’s a genuine, well-documented difference worth knowing, though: for the same topology, a RIPng route will often show a metric one hop higher than the equivalent RIPv2 route would. This isn’t a design flaw or a misconfiguration — it comes down to exactly when each protocol increments its metric. RIPv1 and RIPv2 increment their metric outbound, as a route is sent to a neighbor.
RIPng increments its metric inbound instead, as a route is received and added to the local routing table or RIP database. That single difference in timing is enough to make an otherwise identical topology report metrics that are consistently one hop apart between the two protocols — it’s a documented characteristic of how Cisco’s RIPng implementation works, not an error in either protocol.
[See Infographic: Why RIPng Reports One More Hop Than RIPv2 for the Same Path]
RIPng vs. OSPFv3 for Real IPv6 Networks
RIPng is worth learning thoroughly for CCNA study, but it’s rarely the right choice for a real IPv6 deployment beyond a small lab or legacy environment. OSPFv3 is the modern alternative most production IPv6 networks actually use, and understanding why helps put RIPng’s role in context rather than treating it as an arbitrary exam requirement.
| Aspect | RIPng | OSPFv3 |
|---|---|---|
| Routing type | Distance-vector | Link-state |
| Metric | Hop count (max 15) | Cost, based on interface bandwidth |
| Convergence | Slow — full periodic updates every 30 seconds | Fast — event-driven updates |
| Scalability | Poor beyond small networks | Designed for large, hierarchical networks |
| Path selection | Fewest hops, regardless of link speed | Lowest cumulative cost, reflecting actual link speed |
RIPng’s hop-count metric is its most significant practical limitation: a 1-hop path over a slow link is preferred over a 2-hop path over a much faster one, since RIPng has no concept of bandwidth at all. OSPFv3, using link-state routing and a cost metric tied to actual interface bandwidth, avoids this problem entirely and converges far faster after a topology change, since it doesn’t wait for a periodic 30-second update cycle to propagate news of a failure.
None of this makes RIPng worthless to learn — its simplicity is exactly what makes it a good starting point for understanding IPv6 dynamic routing concepts before tackling OSPFv3’s additional complexity, and it remains directly relevant to CCNA exam topics. But for an actual production network, especially one of any real size, OSPFv3 is almost always the better fit.
Troubleshooting RIPng
No routes appearing at all. Confirm ipv6 unicast-routing is enabled globally — RIPng, like every IPv6 routing feature, depends on it being turned on first. Then confirm the interfaces expected to participate actually have ipv6 rip RIPNG_PROC enable applied, using show running-config | section interface.
Routes appear on some routers but not others. Check that the same process name doesn’t need to match exactly across routers — since it’s locally significant — but that every router actually has RIPng enabled on the interfaces connecting it to its neighbors, not just on its LAN-facing interfaces.
A default route isn’t propagating. Confirm the static ipv6 route ::/0 entry actually exists on the originating router with show ipv6 route static, and confirm default-information originate is present under that router’s RIPng process with show running-config | section ipv6 router rip.
Frequently Asked Questions
What are the key differences between RIPng and RIPv2?
RIPng is built for IPv6 and is enabled per interface rather than through global network statements, uses UDP port 521 and multicasts to FF02::9 instead of RIPv2’s UDP port 520 and 224.0.0.9, and relies on IPsec rather than RIPv2’s built-in MD5 authentication. Both protocols share the same underlying distance-vector design, the same 15-hop maximum, and the same administrative distance of 120, so the core routing behavior transfers directly between them even though the configuration commands differ.
How do I enable RIPng on a Cisco router interface?
First enable ipv6 unicast-routing globally, then create the RIPng process with a locally significant name using ipv6 router rip <process-name> in global configuration mode. From there, enter each interface that should participate and apply ipv6 rip <process-name> enable directly — this per-interface step is what replaces the network command used in RIPv2, and it needs to be repeated on every interface, on every router, that should take part in the RIPng domain.
What commands verify a RIPng configuration?
show ipv6 protocols confirms the RIPng process is active and lists which interfaces have it enabled, though it carries less detail than the IPv4 show ip protocols output. show ipv6 route rip shows the actual routes RIPng has learned, displayed with the familiar [administrative-distance/metric] format — for example, [120/2] for a route with a hop count of 2. debug ipv6 rip is useful for troubleshooting live update exchanges, used cautiously given the volume of output it can produce.
How do I propagate a default IPv6 route through RIPng?
Configure a static default route globally with ipv6 route ::/0 <next-hop-address>, then enter the RIPng process with ipv6 router rip <process-name> and add default-information originate in router configuration mode. This second command is what actually causes RIPng to advertise the static default route to the rest of the RIPng domain — without it, the static route stays local to the router it was configured on and never reaches any downstream router.
Why does the same network show a different hop count in RIPng compared to RIPv2?
This comes down to when each protocol increments its metric rather than any error in the topology or configuration. RIPv1 and RIPv2 increment their hop count metric outbound, as a route is sent to a neighboring router, while RIPng increments its metric inbound, as a route is received and installed into the local routing table. That timing difference means an otherwise identical topology will consistently show RIPng routes one hop higher than the equivalent RIPv2 routes — a documented, expected characteristic of Cisco’s RIPng implementation, not a bug to troubleshoot away.
