Skip to content
Log in Sign up My account

Case 01: Addressing Plan and IPv6 Migration

Blueprint 1.1, 1.6.a, 1.6.b, 1.6.c | Difficulty: Medium

Company background

Northwind Provisions is a food distributor with a head office, two warehouses and 38 retail depots across three regions (North, Central, South). It has just acquired a smaller competitor. Management wants one routable address plan across both companies, and the board has set a goal that all customer-facing services be reachable over IPv6 within two years because a large retail customer now requires it.

Current network

Both companies built their networks from 10.0.0.0/8 without a plan. Depot subnets were handed out in the order requests arrived. The head office has dual-stack-capable core switches but IPv6 is not enabled. The two warehouses are joined to the head office by a provider MPLS L3VPN that carries IPv4 only. A new branch of the acquired company has an IPv6-only ISP circuit.

graph TB
    HO["Head office<br/>10.0.0.0/16 and others"]
    WH1["Warehouse 1"]
    WH2["Warehouse 2"]
    D["38 depots<br/>random 10.x.x.0/24"]
    ACQ["Acquired company<br/>overlapping 10.x"]
    MPLS(("Provider MPLS L3VPN<br/>IPv4 only"))
    HO --- MPLS
    WH1 --- MPLS
    WH2 --- MPLS
    D --- MPLS
    ACQ -. "IPv6-only ISP" .- HO

Requirements

Business:

  • One consistent address plan for the combined company, with the ability to add a region without renumbering.
  • Customer-facing web services reachable over IPv6 within 24 months.
  • No outage to depots during the migration.

Technical:

  • Routing tables at the head office must stay small. Each region should be advertised as a single prefix.
  • Management and infrastructure addresses must be separate from user addresses so that ACLs stay short.
  • IPv6 must not depend on a provider that has no IPv6 service today.

Constraints

  • The MPLS provider will not offer IPv6 service for 18 months.
  • The warehouse management system and a legacy label printer fleet are IPv4 only and cannot be upgraded.
  • Budget allows no new WAN circuits.
  • The core switches cannot run NAT.

Design questions

1. Blueprint 1.1 Which IPv4 plan best meets the summarisation requirement for the combined company?

  • A. Keep the current allocations and summarise with the smallest covering prefix at each site.
  • B. Give each region a contiguous block aligned on a bit boundary, split each block into site blocks and within each site into function blocks, and renumber the overlapping acquired subnets into the plan.
  • C. Move the acquired company into NAT behind a single address and leave the rest as is.
  • D. Allocate subnets sequentially from the bottom of 10.0.0.0/8 as requests arrive, and keep a spreadsheet.
Answer: B

Hierarchical, bit-aligned blocks per region let each region be advertised as one prefix, and function blocks inside each site (users, voice, infrastructure, management, loopbacks) keep ACLs short. A fails because organically allocated subnets cannot be summarised without including addresses that belong elsewhere. C hides the overlap but does not give one routable plan, and it breaks inbound access to the acquired services. D is the pattern that caused the current problem. Plan the block sizes with growth in mind; for example a /16 per region with a /22 or /23 per depot leaves room for 38 depots to grow.

2. Blueprint 1.1 The IPv6 plan will use a global unicast prefix of 2001:db8:1000::/36 assigned by the registry. Which allocation is the best fit for the depots?

  • A. A /64 per depot, with VLANs subnetted from it into /80 prefixes.
  • B. A /48 per site, a /64 per VLAN, and region boundaries on nibble boundaries (for example a /40 per region).
  • C. A /56 per depot and a /120 per VLAN to save space.
  • D. A /32 per site so that every site can have its own sub-allocation.
Answer: B

A /48 per site is the common plan, and it gives 65,536 /64 subnets. A /64 per VLAN is required for SLAAC and for features that assume a 64-bit interface identifier. Nibble-aligned boundaries (/40 per region here) make prefixes easy to read and summarise. A and C break SLAAC with prefixes longer than /64 on host VLANs. D wastes address space at a scale the registry will not sustain: a /32 is a provider-sized block.

3. Blueprint 1.6.b The head office, both warehouses and the depots all have dual-stack-capable switches and routers. Which migration approach should the head office campus use?

  • A. Dual stack on all capable devices, with IPv6 routing and security policy deployed alongside IPv4.
  • B. IPv6-only with NAT64 on every access switch.
  • C. Manual tunnels between every pair of switches.
  • D. Wait until the provider offers IPv6 before enabling anything.
Answer: A

Where the hardware supports both, dual stack is the default and the end state. It allows hosts and services to move one at a time and keeps IPv4-only devices working. B needs a translator the core cannot run and would break the IPv4-only systems. C creates a mesh of tunnels where native links already exist. D delays work that does not depend on the WAN: campus and data center dual stack can proceed now.

Exam trap

Dual stack doubles the control-plane and policy state. The design must budget for both families in ACLs, routing, monitoring and DNS.

4. Blueprint 1.6.a The warehouses and depots need IPv6 now, but the MPLS provider offers no IPv6 for 18 months. What is the best interim design?

  • A. Build IPv6-in-IPv4 tunnels (for example manual GRE or IPv6IP) between the head office and each site over the existing MPLS L3VPN, and replace them with native IPv6 when the provider is ready.
  • B. Order new IPv6 circuits for every depot.
  • C. Use NAT64 at every depot.
  • D. Stay IPv4-only until the provider is ready.
Answer: A

An overlay tunnel carries IPv6 across an IPv4-only core without any change by the provider, and the cost is small. Plan for the tunnel overhead (the IPv6 payload gets a 20-byte outer IPv4 header, more with GRE) by adjusting MTU, and keep tunnel endpoints within the summarised address plan. B contradicts the no-new-circuits constraint. C is a translation tool for IPv6 clients reaching IPv4 servers, not a way to carry IPv6 across an IPv4 network. D leaves the 24-month goal exposed to the provider schedule; tunnels keep progress independent of it.

5. Blueprint 1.6.c The acquired branch has an IPv6-only ISP circuit. Its users need to reach the legacy IPv4-only warehouse management system. Which design element is required?

  • A. NAT64 with DNS64 at the head office edge.
  • B. A second IPv4 address on each user PC.
  • C. Dual stack on the legacy label printers.
  • D. 6to4 tunnels on the branch router.
Answer: A

NAT64 translates IPv6 packets from IPv6-only clients into IPv4 toward the IPv4-only server, and DNS64 synthesises AAAA records for IPv4-only names so clients use the NAT64 prefix (the well-known prefix is 64:ff9b::/96). B does not help an IPv6-only circuit. C is not possible, because the printers cannot be upgraded. D is a tunnel mechanism for IPv6 islands across IPv4, not a translation to an IPv4-only server.

6. Match each IPv6 migration technique to its category. Blueprint 1.6

Technique Category
Dual stack ?
Manual IPv6-in-IPv4 tunnel ?
NAT64 with DNS64 ?
Answer
Technique Category
Dual stack Native (1.6.b)
Manual IPv6-in-IPv4 tunnel Overlay (1.6.a)
NAT64 with DNS64 Boundary translation (1.6.c)

Renumber into a hierarchical IPv4 plan with one prefix per region, and use a /48 per site and /64 per VLAN for IPv6. Run dual stack in the head office and wherever the hardware allows. Join IPv6 islands over the IPv4-only MPLS with tunnels until the provider offers native service. Use NAT64 and DNS64 at the head office edge for the IPv6-only branch to reach IPv4-only systems.

graph TB
    HO["Head office<br/>dual stack"]
    NAT["NAT64 and DNS64"]
    WH["Warehouses<br/>dual stack"]
    D["Depots<br/>dual stack"]
    MPLS(("MPLS L3VPN<br/>IPv4 only"))
    ACQ["Acquired branch<br/>IPv6-only ISP"]
    HO --- NAT
    HO --- MPLS
    WH --- MPLS
    D --- MPLS
    HO -. "IPv6 tunnels over IPv4" .- WH
    HO -. "IPv6 tunnels over IPv4" .- D
    ACQ --- NAT