IPv6 Readiness: What Small Businesses Should Test

Your internet connection can pass an IPv6 test while your VPN, printers, or firewall still have problems. For a small business, IPv6 readiness means proving that connectivity, business applications, and security controls work together.

A limited dual-stack pilot , with IPv4 and IPv6 running side by side, lets you check those layers without changing the entire office. Start with a few representative devices, record clear pass/fail results, and keep a tested rollback path before expanding.

Key Takeaways

• A successful IPv6 ping proves basic reachability, but it doesn't validate application behavior or firewall protection.
• Test staff, guest, voice, and management networks separately because working restrictions on IPv4 don't automatically cover IPv6.
• Keep IPv4 available during the pilot, force IPv6 for selected tests, and stop deployment when business-critical workflows or security checks fail.

Define Your IPv6 Readiness Test Scope

Inventory the paths that matter

Record your internet provider, firewall model and firmware, switches, access points, VPN, and important devices. Then identify Microsoft 365, accounting software, payment systems, hosted phones, file shares, and vendor support connections.

Map staff, guest, voice, camera, and management networks. For each pilot device, record its network segment, switch port or Wi-Fi network, addresses, gateway, and DNS servers.

Use a small business network documentation checklist to keep this baseline organized. Include current firewall configurations and public DNS records so support staff can compare conditions before and after changes.

Set ownership and acceptance criteria

Ask your provider whether the connection includes native IPv6, how it delivers the prefix, and whether that prefix can change. Confirm IPv6 support with your firewall and VPN vendors.

Assign one person to record results and one person who can authorize rollback.

Pass: Every critical system has a test owner and documented expected behavior.
Fail: The deployment depends on undocumented settings, unknown vendor requirements, or nobody being available to reverse changes.

Verify Address Assignment Before Internet Tests

Check addresses, prefixes, and routes

On Windows, ipconfig /all shows interface addresses and DNS settings. Use route print -6 to inspect IPv6 routes. On Linux, ip -6 addr and ip -6 route provide equivalent information.

An address beginning with fe80: is link-local. Its presence alone doesn't prove internet connectivity. Internet-facing clients normally need a global IPv6 address and a usable default route.

Ordinary LANs using Stateless Address Autoconfiguration (SLAAC) generally use a /64 prefix. Confirm that each segment receives its intended prefix rather than copying IPv4 subnet sizes into the IPv6 plan.

Test real client behavior after reconnecting

Router Advertisements communicate IPv6 router information. DHCPv6 can supply addresses or other settings, but it doesn't replace Router Advertisements for default-router discovery.

Test the operating systems and device types your business actually uses. Reboot a pilot device, reconnect Wi-Fi, and renew its configuration using the supported method.

Pass: Devices consistently receive the intended address, route, and DNS configuration.
Fail: Reconnecting changes the network unexpectedly, removes the default route, or leaves required devices without usable settings.

Separate Connectivity Tests From Application Validation

Prove the IPv6 path directly

On Windows, try ping -6 2606:4700:4700::1111 , Cloudflare's public DNS address. Then use tracert -6 2606:4700:4700::1111 to investigate the route.

These are useful diagnostics, although some networks filter echo requests or traceroute responses. A missing reply alone doesn't establish that all IPv6 traffic is broken.

Next, use curl with -6 against an approved, IPv6-capable HTTPS endpoint. Compare the result with -4 . On Windows PowerShell, invoke curl.exe explicitly to avoid confusion with aliases.

Pass: A forced IPv6 connection reaches the destination and completes TLS successfully.
Fail: Forced IPv6 connections repeatedly fail while equivalent IPv4 connections work.

Check transfers and preserve IPv4

Small packets can succeed while larger transfers stall because Path MTU Discovery isn't working. Therefore, test a permitted download and upload rather than stopping after ping.

Compare transfer completion, delays, and interruptions with your IPv4 baseline. Repeat from wired and wireless pilot devices.

Existing IPv4-only equipment can remain in service if its required workflows still work and network restrictions remain intact.

Validate DNS Before Publishing AAAA Records

An A record identifies an IPv4 address. An AAAA record identifies an IPv6 address. Check both for business-owned public services and any internal hostname you're changing.

For a known IPv6 destination, nslookup -type=AAAA one.one.one.one demonstrates an AAAA lookup. For your own services, compare the returned records with the approved address inventory.

Publishing an AAAA record makes that IPv6 address available to clients. Before publishing, confirm that the destination accepts the intended connections, presents the correct TLS certificate, and has the required firewall protection.

However, an IPv4-only vendor service doesn't fail your readiness review merely because it lacks an AAAA record. Document that dependency and retain its working IPv4 path.

Also test internal DNS over the VPN and through your approved resolvers.

Pass: Changed records resolve correctly and lead to the intended, protected service.
Fail: Stale AAAA records, incorrect destinations, inconsistent resolution, or broken internal lookups remain unresolved.

Test Complete Business Workflows

Exercise the applications employees depend on

Connectivity checks establish a network path. Application validation proves that employees can finish their work.

Using pilot accounts, sign in to Microsoft 365, send email, open a shared document, and complete a file-sync operation. Then test accounting, scheduling, CRM, and other business-critical software.

For printers, submit a print job and test scan-to-email or scan-to-folder where applicable. For hosted phones, reboot a handset, confirm registration, and test inbound and outbound calls. Repeat a call during controlled data traffic to check audio quality under load.

Record whether each workflow used IPv6, IPv4, or both. A successful workflow that fell back to IPv4 is useful evidence, but it doesn't validate the application's IPv6 path.

Check VPN routing and vendor allowlists

Test remote access from outside the office. Confirm that approved internal services remain reachable and multifactor authentication still applies.

For a full-tunnel VPN, verify that IPv6 traffic follows the required tunnel policy rather than escaping through the employee's local connection. For split tunneling, compare actual routing and DNS behavior with the approved design.

Also ask vendors whether IP allowlists include the new IPv6 addresses or prefixes.

Pass: Critical workflows finish, access restrictions hold, and traffic follows the documented path.
Fail: Sign-ins stall, calls drop, file transfers fail, or VPN traffic bypasses the required controls.

Validate IPv6 Security Separately

Match firewall restrictions across both protocols

Review IPv6 rules directly. Don't assume an IPv4 rule automatically covers IPv6.

Guest devices should have internet access without reaching business systems or management interfaces. Voice devices should reach only their required services. Restrict firewall, switch, and access-point administration to authorized support devices.

Test guest-to-staff blocking over both protocols. If guest client isolation is required, use two guest devices to verify that protection as well.

Globally routable IPv6 addresses still need stateful filtering. Deny unsolicited inbound connections unless the business has approved them. A small business firewall security checklist can support that rule review.

Check exposure and required control traffic

From an authorized external IPv6 connection, test business-owned public addresses for unexpected accessible services. Use known addresses from your inventory rather than expecting a scan to discover every device.

A focused security testing plan helps define permissions and avoid disrupting sensitive systems. Never scan vendor or cloud infrastructure without authorization.

Don't block all ICMPv6. Neighbor Discovery and Path MTU Discovery need appropriate ICMPv6 traffic. Also review RA Guard on switches that support it, allowing legitimate Router Advertisements only through the intended paths.

Pass: Approved services work, prohibited access fails, and denied attempts appear in logs.
Fail: Administrative interfaces are exposed, segmentation fails, necessary control traffic breaks, or security tools miss IPv6 activity.

Prove Monitoring, Failover, and Rollback

Monitor IPv6 separately from IPv4. Otherwise, healthy IPv4 checks can hide an IPv6 outage.

Confirm that your firewall, endpoint protection, and network monitoring tools record IPv6 activity. Generate an authorized blocked connection and verify that support staff can locate its source device, destination, timestamp, and rule.

A network monitoring checklist can help extend existing alerts to the new paths. Use your normal performance baseline instead of arbitrary latency limits.

If you have a backup internet circuit, test failover. Check whether IPv6 remains available, whether the prefix changes, and whether VPNs or vendor allowlists need adjustments.

Before rollout, back up configurations and document the exact reversal steps. Rollback may require restoring firewall settings, Router Advertisements, DNS records, and provider configuration.

Pass: An intentional test failure produces an actionable alert, failover behaves as documented, and rollback restores the baseline.
Fail: Outages remain invisible, backup connectivity bypasses controls, or recovery depends on reconstructing settings from memory.

Expand the pilot only after resolving critical failures. Then repeat the acceptance tests on each newly enabled network segment.

Frequently Asked Questions

Does every device need IPv6 before deployment?

No. Dual-stack networks can support IPv4-only printers, phones, and specialized equipment. Keep their dependencies documented and verify that they remain reachable from the devices that need them.

However, don't remove IPv4 until those dependencies have a supported replacement or migration plan.

Is an online IPv6 test enough?

An online test checks only part of your connectivity. It doesn't prove guest isolation, VPN routing, inbound firewall protection, or application compatibility.

Use it as an initial signal, then validate forced IPv6 connections, complete business workflows, blocked access, and monitoring. Each result should have its own recorded pass/fail decision.

Deploy Only After the Pilot Passes

A successful internet test is the beginning of IPv6 readiness. The deployment is ready when business workflows, access restrictions, and monitoring also pass.

Keep the change small, preserve a tested rollback path , and expand only after fixing critical failures. That gives your business a controlled transition without relying on employees to discover problems during their workday.