A logistics firm with 30 sites on private IPv4 behind NAT is acquiring two companies, adding IoT sensors, and struggling with overlapping addresses and NAT troubleshooting. It needs scalable growth for five years, simple mergers, and reduced translation complexity. Which addressing strategy best supports long-term growth and operational simplicity?
Select an answer to reveal the explanation.
Short Explanation
You've outgrown patching extra rooms onto a crowded house. Building on roomy IPv6 ground ends the overlap battles while NAT stays just for old corners.
Full Explanation
The correct strategy succeeds because provider-independent IPv6 provides effectively unlimited globally unique space that eliminates overlap conflicts across the 30 sites and future acquisitions, supports massive IoT growth without address reclamation, remains stable through ISP changes and mergers, while dual-stack coexistence with existing private IPv4 permits phased migration and confining translation to the legacy Internet edge reduces troubleshooting and state burden. By contrast, consolidating onto a centrally coordinated 10.0.0.0/8 plan can temporarily resolve overlaps but leaves the firm constrained by finite RFC1918 space and forces disruptive renumbering for every merger, failing long-term scalability and merger simplicity while preserving translation dependence. Acquiring public IPv4 for every host restores end-to-end reachability in theory but fails in practice because public IPv4 exhaustion makes large contiguous blocks unavailable, prohibitively expensive, and unsustainable for five-year IoT expansion. Using ISP-provided provider-aggregatable IPv6 scales technically but creates provider lock-in, so any ISP change or multi-provider merger requires large-scale renumbering and policy rework, undermining the requirement for simple mergers and provider independence. On exams, distinguish provider-independent versus provider-aggregatable addressing when longevity and merger flexibility are tested, and in practice validate the plan by auditing current overlaps and translation state tables, confirming a PI assignment and IPv6-capable hardware, then piloting dual-stack at one site before enterprise rollout.