IPv6 for Enterprise Networks: Why and How to Deploy

IPv6 for enterprise networks is no longer a research topic. It is a planning decision. IPv4 addresses are exhausted, users and devices keep multiplying, and some of your customers, staff and partners will increasingly reach you over IPv6-only access. The practical answer for most organisations is a phased dual-stack deployment: run IPv6 alongside IPv4, start with a limited scope, secure it as deliberately as you secure IPv4, and move towards IPv6-only only where the applications allow it.

This guide explains why organisations enable IPv6, what the security risks are, and how to plan a rollout across a multi-site network. It draws on guidance from ETSI, RIPE NCC, Jisc, NHS England Digital, NIST, APNIC and ARIN.

Re-solution

Plan a More Resilient Network

Re-solution provides Cisco network solutions, infrastructure audits and network surveys to help organisations plan their connectivity.

Explore network solutions

TL;DR

IPv6 matters because IPv4 address exhaustion and growth in users, devices and internet-dependent services make preparation necessary.
IPv4 and IPv6 cannot communicate directly, so most enterprises run both in parallel (dual-stack) during the transition.
IPv6 may already be active on your “IPv4-only” network, and unmanaged IPv6 is a security gap. Firewalls, monitoring and policies need to be IPv6-aware.
Begin with a contained first project, such as public-facing services, Wi-Fi or a testbed, after assessing equipment, software, monitoring and cloud support.
Treat IPv6 as a planned, phased programme, not an addressing swap done in one change window.

Why IPv6 matters for enterprise networks
What actually changes with IPv6
Benefits you can reasonably expect
Security: the part that is easy to get wrong
How to deploy IPv6 alongside IPv4
A readiness checklist before rollout
Moving towards IPv6-only
Our perspective
How Re-solution can help
FAQ
Sources

Why IPv6 matters for enterprise networks

The starting point is scale. ETSI’s enterprise deployment report says IPv6 is important because IPv4 address exhaustion, together with continued growth in users, devices and internet-dependent services, makes preparation necessary. It also describes IPv6 as a scalable foundation for future connectivity and enterprise services.

The second driver is reachability. RIPE NCC explains that IPv4-only content and services may be unreachable to users on IPv6-only access, so externally delivered services should be reachable over both protocols. For a university, a hotel group or a logistics operator with public portals, that is a customer-facing concern, not a back-office one.

The third driver is timing. RIPE NCC’s business guidance advises enterprises to begin IPv6 planning early, because delaying deployment can threaten the long-term return on technology investment and make the eventual transition harder. Equipment bought today will still be in service when IPv6 is the default, so IPv6 support belongs in every refresh and procurement decision now.

What actually changes with IPv6

The address format is the visible difference, but the operational model changes too. NHS England Digital notes that IPv6 uses 128-bit addresses where IPv4 uses 32-bit addresses, and standardises a 64-bit subnet size. That removes most of the subnet-sizing arithmetic that IPv4 networks depend on, and it changes how addressing plans are designed.

Area	IPv4	IPv6
Address length	32 bits	128 bits
Typical subnet size	Variable, often sized to fit scarce space	Standardised at 64 bits
Address assignment	Mostly DHCP or static	Auto-configuration and DHCP support
Reliance on NAT	High, to conserve addresses	Reduced as a primary need
Multicast	Supported, less used	Built in as a core capability

Two practical consequences follow. First, addressing plans become hierarchical and structured rather than conserved, which makes summarisation and route design cleaner. Second, tools that assume IPv4, such as spreadsheets for address tracking, older IPAM systems and monitoring templates, need review before they can describe an IPv6 estate.

Benefits you can reasonably expect

NHS England Digital lists the reasons organisations enable IPv6: a larger address space, simpler packet headers, auto-configuration, DHCP support, multicast, traffic engineering and a reduced primary need for NAT. ETSI adds scalable connectivity, automated management, mobility, simplified administration and better support for growth in connected devices.

For enterprise operators, these translate into a few concrete outcomes:

Room to grow. IoT sensors, building systems, handheld scanners and guest devices no longer compete for scarce address space.
Simpler administration. Standard subnet sizes and auto-configuration reduce per-segment design work.
Fewer translation layers. With less dependence on NAT, traffic paths are easier to trace and troubleshoot.
Future reachability. Services published over both protocols stay accessible as more access networks move to IPv6.

Be realistic about internal benefits. ARIN’s enterprise analysis points out that the gains inside an intranet depend as much on application, supplier and operational-system readiness as on routers and address space. Switching on IPv6 in the core delivers little if the applications behind it cannot use it.

Security: the part that is easy to get wrong

IPv6 is not less secure by nature, but it is frequently less managed. Jisc warns that IPv6 may already be active on networks believed to be IPv4-only, because common operating systems support it and often enable it by default. Unmanaged IPv6 can allow rogue Router Advertisements, where a device impersonates a router or hands other devices bad DNS information. Jisc’s recommendation is to deploy IPv6 deliberately and manage it proactively.

The standards bodies agree on the principles:

Aim for parity. ETSI says enterprise IPv6 security should reach at least parity with IPv4 security, and account for protocol-specific issues including extension headers and ICMPv6.
Update policy and firewalls. ETSI also says firewalls must permit the ICMPv6 message types the protocol needs while blocking or permitting others according to policy, and that security policies should be updated for IPv6. Blocking all ICMPv6 as a habit carried over from IPv4 breaks core protocol functions.
Make controls IPv6-aware. NIST’s IPv6 bulletin warns that security controls which do not monitor IPv6 may fail to detect IPv6 traffic, and recommends that controls handle both protocols.
Integrate, do not bolt on. NIST SP 800-119 treats IPv6 as something to integrate into existing security architecture and lifecycle controls, not merely an addressing upgrade.

Dual-stack adds its own load. NIST notes that running both protocols increases complexity, because organisations may need IPv4 for legacy applications, services and clients while introducing IPv6. Every rule, log pipeline and access policy now exists twice, and the two copies must stay consistent.

If you are reviewing perimeter and access controls anyway, our guides on the firewall audit checklist and network access control cover the controls that need an IPv6 pass.

How to deploy IPv6 alongside IPv4

NHS England Digital states plainly that IPv4 and IPv6 cannot communicate directly, which is why operators generally run both in parallel during the transition. APNIC’s deployment guidance likewise presents dual-stack as the general method for carrying both protocols while deployment proceeds, with transition mechanisms where traffic must cross between them.

ETSI is clear that there is no single enterprise IPv6 design: architects must choose an approach appropriate to their own situation. Jisc’s UK guide gives the most useful framing: treat IPv6 as a planned, phased deployment rather than an all-at-once change. NIST SP 800-119 also recommends a phased approach, using suitable transition mechanisms and a deliberate mix of address types, including privacy, unique-local and sparse allocation approaches.

Pick a first project

Jisc suggests several contained starting points: public-facing web, DNS and mail services, Wi-Fi, research networks, laboratories, or an isolated testbed. Wi-Fi is worth particular attention. Jisc says a Wi-Fi IPv6 deployment can typically result in 30 to 40 per cent of Wi-Fi traffic being IPv6, possibly more, so the effect is visible quickly and the lessons carry over to the wider network.

If your first project is wireless, a survey before rollout confirms that coverage and capacity are sound before you change addressing on top of it. See our notes on why a wireless site survey pays off.

Choose a transition mechanism

Mechanism	What it does	When it fits
Dual-stack	Runs IPv4 and IPv6 side by side on the same devices and links	The default for most enterprise networks
Tunnelling	Lets IPv6 devices communicate across IPv4-only parts of the network	Connecting IPv6 islands before native links exist
NAT64 / DNS64	Lets IPv6-only clients reach IPv4 devices	IPv6-only segments that still need IPv4 content
464XLAT	Handles IPv4-only applications on IPv6-only clients	Mobile apps that cannot use IPv6

The descriptions of tunnelling and NAT64 follow NHS England Digital, and the use of NAT64, DNS64 and 464XLAT for IPv4-only content follows Jisc’s guide.

A readiness checklist before rollout

NIST’s secure-deployment guidance says to assess IPv6 support across network devices, applications, security controls, monitoring, management systems and operational processes before anything changes. ARIN adds practical dependencies: application support, network modelling, firewall change management, supplier and partner support, and legacy equipment. Putting these together gives a sequence that works for a multi-site organisation.

Organise the team and the scope. Name an owner across networking, security and applications. IPv6 cuts across all three.
Inventory and assess. List routers, switches, wireless controllers, firewalls, load balancers, servers, applications, monitoring, IPAM and cloud services, and record which support IPv6 and which do not. Include supplier and partner connections.
Check what is already running. Because IPv6 may be enabled by default on endpoints, look for existing IPv6 traffic and rogue Router Advertisements before you plan anything new.
Design the addressing plan. Use the standard 64-bit subnet size, a hierarchical layout per site and function, and a deliberate decision on address types.
Build a proof of concept. Use a testbed or one contained service, with firewall rules and monitoring in place from day one.
Secure and monitor. Extend policies, logging, firewall rules and intrusion detection to both protocols, with ICMPv6 handled according to policy.
Deploy in stages. Work outwards from the internet perimeter, one layer 3 hop at a time, and test connectivity for both IPv4 and IPv6 users at each stage.
Train people. Operations staff need to read IPv6 addresses, logs and troubleshooting output with confidence before they carry the production network.

For the structured version of the audit step, our network audit checklist and network infrastructure checklist give a documented way to record findings, and network architecture basics is useful when the addressing plan feeds into a wider redesign.

Moving towards IPv6-only

IPv6-only is a destination, not a first step. NHS England Digital says IPv6-only clients can use NAT64 and DNS64 to communicate with IPv4 devices, but that some mobile apps are IPv4-only and 464XLAT can address this. Its guidance is that dual-stacking is preferable where possible.

So the sensible order is: dual-stack first, measure how much traffic and how many applications still depend on IPv4, then introduce IPv6-only segments where the dependency is low, such as guest Wi-Fi or specific cloud workloads. Keep translation in place for as long as legacy applications, suppliers or devices need it.

Our perspective

We have spent more than 35 years working with Cisco networks, and the pattern we see in IPv6 projects is consistent: the protocol is rarely the hard part. The hard part is the inventory. Multi-site estates in education, manufacturing, logistics and hospitality tend to combine newer cloud-managed equipment with older switches, wireless controllers and specialist devices, and each one has its own IPv6 position.

Our advice is to start with evidence. An infrastructure audit that records what supports IPv6, what is already passing IPv6 traffic and where security controls are blind to it gives you a plan you can defend to the board and to your suppliers. Wireless is usually the best first deployment, because the benefit is visible and the scope can be contained to one site.

We also hold to one security rule: IPv6 gets the same policy, logging and review as IPv4, from the first day it is enabled. Networks get into trouble when IPv6 exists but nobody owns it.

— Jacob

How Re-solution can help

If your team has the intent but not the capacity to inventory, design and secure an IPv6 rollout, we can support the work. Our network audits establish what your estate supports today, and our managed services team can run and monitor the network once dual-stack is live. Where the project sits inside a wider redesign, our professional services cover planning and delivery. For organisations that prefer a subscription model, Network as a Service is also available. Pricing is not published, so contact us with your site count and scope.

You can also read how managed networks benefit IT teams before deciding how much of the rollout to keep in-house.

FAQ

Why enable IPv6 if our IPv4 network works?

IPv4 address exhaustion and growth in devices and services make preparation necessary, according to ETSI. Services that are IPv4-only may also be unreachable to users on IPv6-only access. Enabling IPv6 early lets you plan the change at your own pace rather than under pressure.

Can IPv4 and IPv6 devices talk to each other directly?

No. NHS England Digital states that the two protocols cannot communicate directly. Networks therefore run both in parallel, or use translation such as NAT64 to connect IPv6 devices to IPv4 devices, and tunnelling to carry IPv6 across IPv4 links.

Is IPv6 less secure than IPv4?

Not inherently, but it is often less managed. Jisc notes it may already be enabled on networks believed to be IPv4-only, and NIST warns that controls which ignore IPv6 can miss its traffic. The fix is to make firewalls, monitoring and policies cover both protocols from the start.

Where should an enterprise start?

Start with an assessment of equipment, software, monitoring, firewalls, IPAM and cloud support. Then pick a contained first project such as public-facing services, Wi-Fi or an isolated testbed, as Jisc suggests, and extend in phases.

Should we go straight to IPv6-only?

Generally no. NHS England Digital prefers dual-stacking where possible, because some applications, including certain mobile apps, are IPv4-only. IPv6-only segments work best once you know how much IPv4 dependency remains, with NAT64, DNS64 or 464XLAT covering the gaps.