IPv6 Readiness: 9 Proven Wins for Safer Networks

IPv6 readiness has quietly stopped being a strategic choice and become an operational fact. Internet service providers hand out dual-stack circuits by default, mobile networks have run IPv6-first for years, and every major cloud platform will happily give a workload an IPv6 address without anyone signing off on it. The result is that most small and mid-sized estates already carry IPv6 traffic, and almost none of them have deliberately planned for it. That gap — between the protocol being present and the protocol being managed — is what IPv6 readiness actually means, and it is where the risk lives.

Why IPv6 readiness is no longer optional

The case for deferring IPv6 used to be straightforward: IPv4 worked, nothing forced a change, and the migration looked like a project with no visible payoff. That calculation has shifted. Carrier-grade NAT sits between many business connections and the internet, breaking the assumption that a public IPv4 address is something you can rely on. Government and public-sector procurement in several countries now asks suppliers about IPv6 support. Cloud providers charge for scarce IPv4 addresses. None of this forces a big-bang migration, but all of it means the question of IPv6 readiness now turns up in tenders, audits and incident reviews.

The more immediate driver is security. A half-configured dual-stack network is measurably worse than either a clean IPv4-only network or a properly managed dual-stack one. Operating systems have preferred IPv6 over IPv4 by default for more than a decade, so the moment an IPv6 route appears on a subnet, traffic starts using it — and if the firewall rules, logging and monitoring were only ever written for IPv4, that traffic is now invisible. The IETF’s RFC 9099, Operational Security Considerations for IPv6 Networks, is blunt about this: the risk in transition is rarely the protocol itself, it is the mismatch between the controls on one stack and the controls on the other.

So IPv6 readiness is not really a migration project. It is a hygiene programme: find where IPv6 already is, decide where you want it, and make sure every control that applies to IPv4 applies equally to IPv6. The nine steps below are the practical version of that programme, in the order most teams should tackle them.

1. Start with an honest inventory

Every IPv6 readiness exercise that goes badly starts the same way: someone assumes IPv6 is switched off. It usually is not. Windows, macOS, Linux, iOS and Android all ship with IPv6 enabled. Many firewalls and routers will accept a prefix from the ISP without being asked twice. Link-local addressing is always present on an Ethernet segment whether anyone configured it or not.

The first deliverable is therefore a factual picture rather than a plan. For each site and each client tenant, record whether the WAN circuit has an IPv6 prefix delegated, whether the perimeter device is passing IPv6, whether internal subnets carry router advertisements, and whether endpoints have global IPv6 addresses. Packet captures and a walk of the DHCPv6 and neighbour-discovery tables will tell you more in an afternoon than a month of asking vendors. Note which public services already resolve to AAAA records — many SaaS front doors do, which means your users are probably already reaching them over IPv6 from home and mobile networks.

Write it down per tenant, not as a single estate-wide summary. IPv6 readiness varies enormously between a client on a modern fibre circuit and one on an ageing leased line, and the remediation work is completely different for each.

2. Write the addressing plan before you enable anything

IPv4 taught a generation of engineers to conserve addresses. IPv6 rewards the opposite instinct, and teams that carry IPv4 habits across tend to produce plans they regret. A delegated /48 gives you 65,536 /64 subnets; there is no reason to squeeze VLANs into narrower prefixes to save space, and doing so breaks stateless address autoconfiguration.

A workable plan assigns a /64 per VLAN as the default, reserves blocks by function — servers, user networks, guest, management, point-to-point links — and leaves obvious gaps so that later additions land in sensible ranges. Document the mapping between IPv4 subnets and their IPv6 counterparts so that a rule, a route or a firewall object can be located by analogy rather than by search. Decide the policy on static addressing for servers and infrastructure early, because retrofitting it is painful.

Good IPv6 readiness also means deciding what you are not doing. If a client’s line-of-business application is IPv4-only and will be for years, say so in the plan, note the translation or dual-stack arrangement that covers it, and move on. Undocumented exceptions are how estates end up half-migrated for a decade.

3. Bring firewall rules to full parity

This is the single highest-value item on the IPv6 readiness list. Most firewall platforms treat IPv4 and IPv6 rule bases separately. A policy that blocks inbound RDP on IPv4 says nothing at all about IPv6 unless someone wrote the matching rule. Teams discover this during penetration tests far more often than during change reviews.

Work rule by rule rather than by exception. For every IPv4 policy, confirm there is an equivalent IPv6 policy, and record explicitly where there deliberately is not. Pay attention to ICMPv6: unlike ICMP on IPv4, it is not optional — neighbour discovery, path MTU discovery and address configuration all depend on it, so blanket-blocking ICMPv6 breaks the network in ways that look like application faults. The Canadian Centre for Cyber Security’s IPv6 guidance sets out which ICMPv6 types need to pass and which can safely be dropped.

Check tunnelling too. Transition mechanisms such as Teredo and 6to4 can carry IPv6 traffic out of a network that believes it is IPv4-only, straight past the rules you spent the afternoon writing. Unless you are deliberately using them, block them at the perimeter and on endpoints.

4. Close the monitoring and logging blind spot

A firewall can pass IPv6 traffic perfectly well while logging almost none of it. The same is true of flow collectors configured for IPv4 flows only, intrusion detection rules written against IPv4 address objects, and SIEM parsers that quietly drop events whose source field does not match a dotted-quad pattern. This is the part of IPv6 readiness that generates the most unpleasant surprises during incident response, because the gap only becomes visible when someone needs the data and it is not there.

Test it rather than assume it. Generate known IPv6 traffic, then go and find it in the flow data, the firewall logs, the proxy logs and the SIEM. Check that address normalisation is consistent — abbreviated and fully expanded IPv6 addresses are the same address, but a naive correlation rule will not agree. Confirm that retention, alerting thresholds and dashboards cover both stacks. If your detection content references IPv4 CIDR ranges for “internal”, it needs an IPv6 equivalent or it will treat your own network as external.

5. Get DNS and resolution order right

Publishing an AAAA record is the moment IPv6 becomes real for users, because clients implementing Happy Eyeballs will try the IPv6 path first and only fall back after a delay. If the IPv6 path is broken or slower, users experience it as an application that “feels sluggish” — a symptom that almost never gets diagnosed as an IPv6 problem on the first call.

Practical IPv6 readiness here means: do not publish an AAAA record until the service behind it is genuinely reachable and monitored over IPv6; make sure your recursive resolvers answer over both protocols; confirm reverse DNS exists for infrastructure addresses, since mail and logging systems care; and test from a genuinely IPv6-native network rather than from the office, which may still be IPv4-only. Mobile tethering is a useful free test bed for exactly this.

6. Audit the tooling that assumes IPv4

Networks are usually more ready than the software managing them. Remote monitoring and management agents, backup appliances, VPN clients, licence servers, access control lists inside applications, allow-lists on third-party APIs — any of these may store an address in a field sized for IPv4, or validate input against a dotted-quad regular expression. An honest IPv6 readiness assessment tests the management plane as carefully as the data plane.

Build a short matrix of every tool in the stack against three questions: does it work over IPv6, does it record IPv6 addresses correctly, and does it let you write policy using IPv6 objects? Vendors’ answers to the first question are frequently more optimistic than their answers to the other two. Where a tool fails, that is not a blocker for the whole programme — it is an exception with an owner and a review date.

7. Control rogue router advertisements

On an IPv6 segment, any device can announce itself as a router. A misconfigured laptop with internet connection sharing enabled, a home router someone plugged into a spare port, or a virtualisation host with an unintended bridge can all start advertising a prefix — and well-behaved clients will believe it. The IPv4 equivalent, a rogue DHCP server, is a familiar problem; the IPv6 version is less well known and often unmitigated.

The controls are straightforward and belong in every IPv6 readiness checklist: enable RA Guard on access switches, enable DHCPv6 Guard where the platform supports it, and add first-hop security to the standard switch configuration template so that new sites inherit it. Then monitor for unexpected router advertisements as a detection of last resort. This is cheap to configure once and expensive to discover the hard way.

8. Rewrite runbooks and service desk scripts

Documentation is where IPv6 readiness usually stalls, because the work is unglamorous and nobody is measured on it. Yet a runbook that says “check the IP address” without specifying which stack, or a diagnostic script that only ever pings the IPv4 gateway, will send engineers down the wrong path during an outage.

Go through the standard troubleshooting flows and make them stack-aware. First-line scripts should capture both addresses, and should include a simple “does it work if you force IPv4?” test, because that single question separates IPv6 path problems from everything else in about thirty seconds. Escalation notes should record which protocol the fault was observed on. Network diagrams need the IPv6 prefixes added, not just the IPv4 subnets. Firewall change templates need an IPv6 section that cannot be left blank.

Bring the service desk into this deliberately. A team that has never seen an IPv6 address will not recognise one in a ticket, and that recognition gap costs more troubleshooting time than any configuration error.

9. Give the work a named owner

Every item above is achievable. What defeats most teams is that IPv6 readiness has no deadline, no customer chasing it and no dashboard turning red, so it loses to whatever is on fire today. It is continuous hygiene work, and continuous hygiene work without an owner does not happen.

The practical answer is to name one engineer, give them a recurring block of protected time, and define what “done” looks like per tenant: inventory complete, addressing plan written, firewall parity verified, logging tested, first-hop security deployed, runbooks updated. Track it per client as a simple status, review it monthly, and let it take as long as it takes. What matters is that it moves every month rather than being rediscovered annually.

That is a hard role to fill from an already-stretched team. Senior network engineers are the people you least want pulled off escalations, and IPv6 readiness is not urgent enough to justify taking them off. Which is precisely why it suits dedicated, additional capacity rather than reallocated capacity.

How to staff IPv6 readiness without stalling BAU

This is the pattern OutsourceZA sees across UK and EU managed service providers: the plan is sound, the priorities are agreed, and the work still does not start because every engineer capable of doing it is already committed to tickets and projects with client-visible deadlines.

Outstaffing solves the arithmetic rather than the willpower. South African tech talent is deep in exactly the disciplines this work needs — network engineering, infrastructure operations and MSP tooling — typically at 40 to 60 percent of equivalent UK cost. Because South Africa sits in a timezone that overlaps the full UK and most of the EU working day, an outstaffed engineer is not a night shift handing over notes; they are in the same stand-ups, the same change reviews and the same chat channels as your local team. For a programme like IPv6 readiness, which is mostly steady progress punctuated by questions that need a quick answer from someone who knows the estate, that overlap is the difference between real momentum and a quarterly status update.

The flexibility matters too. IPv6 readiness is front-loaded: heavy on discovery, planning and firewall work in the early months, then lighter as it becomes routine. Outstaffing lets you scale a dedicated engineer up for the programme and redeploy them onto other infrastructure hygiene afterwards — certificate lifecycles, monitoring coverage, firmware cycles — without the commitment of a permanent local hire. You can read more about how we work, or talk to us about scoping the capacity you would need to get IPv6 readiness onto a schedule instead of a wish list.

IPv6 readiness FAQ

Do we have to migrate to IPv6 right now?

No. Dual-stack is the mainstream approach and there is no need to switch anything off. What is urgent is the assessment: knowing where IPv6 is already carrying traffic, and making sure your security controls cover it. IPv6 readiness in that sense is defensive work you should do regardless of migration timing.

Is disabling IPv6 a valid strategy?

It is a decision you can make, but it must be implemented deliberately and verified across every device, not just assumed. Partial disabling often creates a worse position than dual-stack, because some paths use IPv6 while the controls and logging assume it is absent. Some services — including parts of Windows networking — also behave unpredictably when IPv6 is switched off entirely.

How long does an IPv6 readiness programme take?

For a single-site SME, the inventory and firewall parity work is typically a matter of weeks. For an MSP running dozens of client tenants, it is a rolling programme measured in quarters, because each tenant needs its own assessment, plan and verification. The realistic target is steady progress against a tracked list rather than a single completion date.

What breaks most often during IPv6 rollout?

In practice: over-blocked ICMPv6, monitoring that silently misses IPv6 flows, AAAA records published before the service behind them was properly reachable, and management tooling that cannot store or filter on IPv6 addresses. All four are found by testing rather than by reading documentation.

Can outstaffed engineers do this work safely on client networks?

Yes, under the same access controls, change management and supervision as any other member of your team. Outstaffed engineers work as an extension of your organisation rather than as an external vendor, which is what makes them suitable for sustained estate work. If you are hiring into this space yourself, our IT jobs board shows the kind of network and infrastructure roles we recruit for.

Where should a team start if they only have one day?

Spend it on steps one and three. Establish whether IPv6 is live on the perimeter and internal subnets, then compare the IPv4 and IPv6 firewall rule bases. If those two things are known and consistent, the rest of the IPv6 readiness programme is planning work rather than exposure.