← Operator library Network Engineering

IPv6 Deployment for ISPs: A MikroTik Migration Runbook

Plan addressing, prefix delegation, routing, security and customer migration before enabling IPv6 across a MikroTik access network.

What this note covers

Plan addressing, prefix delegation, routing, security and customer migration before enabling IPv6 across a MikroTik access network.

Treat IPv6 as an address-management programme

IPv6 deployment is not an interface toggle. An ISP must obtain routable space, design aggregation, delegate stable customer prefixes, preserve security parity with IPv4, and create an operating model that support staff can troubleshoot. Dual stack is usually the least disruptive first state, but it doubles the number of paths that must be observed.

Address plan

Reserve infrastructure, loopback, access, customer delegation and growth blocks before configuration.

Delegation

Choose a consistent residential or business prefix size and retain the customer-to-prefix history.

Routing

Advertise aggregates while keeping access failures and accidental specifics contained.

Operations

Make DNS, monitoring, abuse handling and customer support IPv6-aware before launch.

Build an allocation hierarchy

Start with the RIR or upstream allocation and divide by purpose, geography and failure domain. Avoid encoding transient VLAN numbers into a plan that must last for years. A customer prefix should remain stable when practical, while the database records who held it and when.

Use /127 or carefully controlled /64 infrastructure links according to platform support, and delegate rather than bridge a shared /64 to residential routers. A /56 gives a customer room for multiple LANs; the commercial policy should be explicit.

Deploy dual stack deliberately

Establish IPv6 routing and firewall policy on the management plane first, then a lab access concentrator, staff users and a bounded customer pilot. Router advertisements and DHCPv6 prefix delegation solve different jobs; confirm the CPE behaviour used in the field.

Do not copy an IPv4 NAT mindset. Filter unsolicited inbound traffic at the customer edge and protect router services, while allowing required ICMPv6 for neighbour discovery, path MTU discovery and error reporting.

Measure what users experience

Monitor recursive DNS over both families, route reachability, prefix-delegation success and application timing. A website may appear healthy over IPv4 while broken AAAA records send IPv6-capable customers into a timeout.

Keep a rollback that withdraws the pilot advertisement and delegation policy without deleting the allocation records needed for investigation.

Operational caution: Blocking all ICMPv6 breaks core protocol functions. Build a documented allow-list by message type instead of applying an IPv4-era blanket drop.

Evidence before rollout

Signal Required proof
Address inventory Every aggregate, infrastructure subnet and delegation pool has an owner and purpose.
CPE pilot Representative routers retain a delegated prefix through renewals and reconnects.
Security parity Input, forwarding and management controls are tested over IPv6, not assumed from IPv4.
DNS path Authoritative and recursive services answer correctly over both address families.
Route visibility Expected aggregates appear upstream without leaked customer specifics.

Put the plan into operation

  1. Acquire. Confirm allocation, upstream routing and route-object requirements.
  2. Design. Create the hierarchy, delegation sizes, retention rules and reverse-DNS model.
  3. Lab. Test RouterOS, RADIUS attributes, CPE models, MTU and firewall behaviour.
  4. Pilot. Enable staff and a small customer cohort with enhanced monitoring.
  5. Expand. Roll out by access domain while comparing failure and support rates.
  6. Review. Remove temporary exceptions and document operational ownership.

The decision standard

Approve broad rollout only when one prefix can be traced from allocation to customer, the CPE survives renewal, IPv6 security matches the intended policy, and support can isolate DNS, routing, delegation and device faults independently.

Research basis: IETF RFC 8200; IETF RFC 8415; MikroTik RouterOS IPv6 documentation; RIPE IPv6 for ISPs guidance. Validate implementation details against the releases, contracts, and local regulations governing your network.

Continue with ISPbills

Put this guide into practice