A township board is adding IPv6 dual-stack on the same campus where OSPFv2 already carries IPv4. Which statement correctly describes the OSPF design?
Select an answer to reveal the explanation.
Short Explanation
Dual-stack doesn’t mean one OSPF to rule them all on day one. OSPFv2 keeps hauling IPv4; OSPFv3 shows up for IPv6. Same campus, two address families, two processes playing nice side by side.
Full Explanation
On a dual-stack campus, OSPFv2 continues to carry IPv4 while OSPFv3 carries IPv6; the two processes coexist. A township board adding IPv6 dual-stack where OSPFv2 already carries IPv4 should run OSPFv3 for IPv6 alongside OSPFv2 for IPv4 rather than assuming one process magically replaces both address families without design work. That coexistence model is the correct OSPF design statement for dual-stack civic campuses during IPv6 adoption.
Replacing OSPFv2 with a single OSPFv3 process that automatically advertises both IPv4 and IPv6 without address-family configuration oversimplifies modern OSPFv3 address-family modes and is not the safe default mental model for this item. Using only RIPng for IPv6 because OSPFv3 cannot form adjacencies on Ethernet campuses is false. Redistributing IPv6 connected routes into OSPFv2 Type-5 LSAs to avoid deploying OSPFv3 is not a valid IPv6 IGP design.
Exam caveat: OSPFv3 configuration details vary by IOS train—verify classic IPv6-only OSPFv3 versus address-family style—but keep IPv4 on OSPFv2 unless you are intentionally migrating with a tested plan. Operational check: enable OSPFv3 on dual-stack interfaces, confirm IPv6 adjacencies and routes, confirm OSPFv2 IPv4 remains stable, and document separate troubleshooting for each process.