IPv6 Readiness: Networks, DNS and Services

Check the Network, DNS and Service Before Publishing IPv6

IPv6 readiness spans the access network, DNS, routing, security and application, and users can reach your sites over IPv6 if both your services and their networks support it. A public adoption chart provides context; it cannot establish that your own endpoint works. If you manage domains, hosting, VPS, dedicated servers or a corporate network, the useful task is to identify dependencies and verify each service path before advertising it.

In this article, we will look at what adoption measurements can tell you, which network and service checks they cannot replace, and how to put together a realistic, low‑risk roadmap. We will also outline dual‑stack design options and concrete steps you can take this month to assess and prepare your infrastructure.

Drivers to Consider in Your IPv6 Readiness Review

IPv4 address space is finite, but exhaustion describes an allocation pool and policy context; it does not mean existing IPv4 addresses stopped working. Address needs, access-network support and applicable contracts can motivate an IPv6 project. Their importance depends on the service you operate.

1. Address Supply and the IPv4 Budget

RIPE NCC announced exhaustion of its remaining available IPv4 pool on 25 November 2019. Its current policy still describes conditional /24 waiting-list allocations, while ARIN documents waiting-list and transfer routes. Check eligibility and availability for the registry concerned. These supply constraints do not prove sustained transfer-price increases: use dated purchase or lease quotes for your own budget. The companion article explaining IPv4 exhaustion, pricing and adaptation covers that context.

When you are planning new services, every additional public IPv4 address starts to feel like a mini‑project: justification, approvals, cost comparison, NAT design. IPv6 flips that model. Within your allocated IPv6 prefix, you can plan generous address ranges for internal and external services, reducing address-conservation pressure and the need for additional NAT layers.

2. Access-Network Capability

Mobile and fixed access networks can offer native IPv6 alongside IPv4 or use an IPv6-first design with translation for IPv4 destinations. The actual service depends on the operator, plan and device configuration. Do not infer that every new subscription includes IPv6 or that most recent growth came from one category without comparable dated measurements.

This has two consequences for you as a site or app owner:

• If your services support IPv6, those users can reach you natively over IPv6, potentially avoiding address translation in the path.
• If you do not support IPv6, access depends on IPv4 connectivity or translation. Congested CGNAT infrastructure can add latency or connection failures, but not every IPv4 path has these problems.

In other words, IPv6 can provide an alternative to a problematic IPv4 path, but any user-experience advantage should be measured on the networks your audience uses.

3. Client Address Selection and Happy Eyeballs

Happy Eyeballs v2 combines asynchronous DNS resolution, address ordering and staggered connection attempts. Attempts need not begin simultaneously; earlier attempts can remain active while later ones start. When one connection succeeds, the other unfinished attempts should be canceled. The address policy can favor IPv6, but this does not guarantee the fastest application response, and fallback can hide a broken IPv6 path. Measure both families explicitly rather than attributing shorter routes or fewer firewalls to IPv6.

Once your service is reachable over IPv6 and its AAAA record is available to clients, IPv6‑capable clients can begin using it without a manual user migration. Do not assume that publishing the record alone establishes working connectivity or guarantees selection of the better-performing path.

4. Named Procurement and Contractual Requirements

A concrete historical example is the U.S. OMB memorandum M-21-07 of 19 November 2020. It set a target for at least 80% of IP-enabled assets on covered federal networks to operate in IPv6-only environments by the end of fiscal year 2025, excluding national security systems. That is a scoped policy target, not an achieved adoption rate or a deadline for every private website. For a particular RFP, record the actual jurisdiction, covered services and required acceptance evidence.

If you serve public institutions, regulated industries or international brands, review the applicable procurement and contractual requirements for IPv6. Document which services support it and any remaining gaps rather than assuming a universal eligibility rule.

Use Dated Measurements to Select Relevant Tests

Measurement platforms count different populations. Preserve the metric name, observation date, geographic or network scope and averaging window before comparing them. A single snapshot cannot establish acceleration, and two rising observations do not show that every country or intervening period grew.

A Service-Specific Global Observation

Google’s published metric is the percentage of users accessing Google over IPv6. Its dataset reports 47.458546%, rounded here to 47.46%, on 2 November 2026. This is a single-day observation for that service, not the share of all internet traffic, devices or people. Keep user capability, selected connections and your own request share separate.

For individual businesses, the relevant metric is your own audience mix, not just the global average. Segment measurements by mobile and fixed access networks and by region rather than assuming a particular IPv6‑capable share for your properties.

Regional Differences Need Comparable Samples

In APNIC’s country map, the 30-day window from 5 October to 3 November 2026 reports IPv6 Capable values of 85.98% for France, 76.44% for India and 22.02% for Turkey. Turkey’s IPv6 Preferred value is 21.04%, from 15,144,848 samples. These are selected country-sample metrics, not continental averages or all-traffic shares. They demonstrate variation in that window, not shrinking gaps or the capabilities of a particular subscriber line.

For a multi‑regional business, assess IPv6 support across the markets and access networks your audience uses. IPv4‑only service does not necessarily exclude those users, but it prevents them from using a native IPv6 path to your service.

IPv6 Support in Hosting Environments

For a dual‑stack deployment, verify IPv6 support in the chosen hosting plan, control panel, reverse proxy and load balancer, including the functions your application needs. A staged rollout is described in our article on building a calm dual‑stack IPv6 playbook with AAAA records and real‑world tests.

Check IPv6 coverage in monitoring, logging and security tools as well as in DNS and CDN services. Client-facing IPv6 support does not by itself establish IPv6 support on every connection through to the origin.

What the Readiness Review Means for Websites and Apps

Identify which user and dependency paths need IPv6, and which must retain IPv4 compatibility. An additional supported path can be useful; its value depends on actual connectivity, operating cost and service requirements. The following checks turn that decision into work the network and application owners can validate.

1. Reachability and User Experience

Users behind heavy CGNAT or strictly managed corporate firewalls sometimes experience unstable IPv4 connectivity. If those same users have a working IPv6 path to your service, your IPv6‑enabled services may actually be the more reliable option.

Symptoms worth investigating for IPv4 path or NAT problems include the following; none establishes that missing IPv6 support is the cause:

• Intermittent timeouts from specific mobile networks while other users are fine.
• Support tickets that cannot be reproduced from your office or test connections.
• Dropped WebSocket or other long‑lived connections where NAT state limits or idle timeouts are involved.

Enabling IPv6 does not automatically fix these symptoms, but it can provide an additional path to your servers whose reliability you can compare with IPv4.

2. Consistent Security Across IPv4 and IPv6

Verify that your firewalls, WAFs, SIEMs and intrusion detection systems handle IPv6 addresses and enforce or monitor the intended policies in a dual-stack environment. Apply consistent access goals using protocol-aware rules rather than blindly copying IPv4 rules. Preserve essential ICMPv6 errors, including Packet Too Big, and assess neighbor discovery and router advertisement traffic for the relevant local links and node roles. The key is to design security for both families, not to bolt IPv6 on at the last minute.

For example, if you run a web application firewall as described in our guide on practical protection with WAF solutions like Cloudflare WAF or ModSecurity, your IPv6 deployment should pass through the same protection layers as IPv4. When you introduce IPv6 early and deliberately, you can test and tune these rules gradually instead of rushing during an emergency migration.

3. Preparing for Future Services and Protocols

Microservices, IoT deployments, container platforms and hybrid environments can benefit from an address plan with room to grow. They can also operate with private IPv4, depending on the platform. Choose IPv6 when the application, discovery and management dependencies support the design; it is not a prerequisite for every modern architecture.

Within the allocated prefix, separate service and environment subnets can reduce overlapping-address problems in hybrid infrastructure. Globally unique addressing does not replace routing, segmentation or access control, and it need not expose internal services to the internet. For device and gateway constraints, the IoT and edge readiness guide examines the device-to-service path separately.

4. Cost and Flexibility on the Hosting Side

Extra public IPv4 addresses can carry acquisition or recurring fees, with prices and limits varying by provider and period. IPv6 offers a much larger address space, but the business case must include retained IPv4 endpoints, translation or proxy capacity, software changes and the cost of operating both families.

A design may reserve public IPv4 for shared entry points and legacy dependencies while using IPv6 internally. Moving an internal service that already uses private IPv4 does not itself remove a public-address charge. Compare the actual number of required public addresses before treating that design as an IPv4 budget reduction.

Practical Impact on Domains, DNS and Hosting Environments

A routing-ready server can still fail through DNS, TLS, a proxy or application logic. Review each layer and its owner before publishing a new public destination.

Domains and DNS: AAAA, Glue and DNSSEC

At the DNS level, enabling IPv6 starts with very small, concrete changes:

• Publish AAAA for a hostname such as www, api or mail only after its IPv6 service and protection have passed tests. Mail also needs its own acceptance checks.
• If you operate delegated nameservers (for example, ns1.yourdomain.com), verify the authoritative hostnames and any required IPv6 glue with the registrar or registry. Ordinary website AAAA publication does not require moving nameservers or adding glue for the website.
• Check DNSSEC validation and CAA policy in the actual resolution and certificate workflow. These DNS functions are separate from whether the client-to-web connection uses IPv4 or IPv6.

If you are new to private nameservers and glue, our article on setting up private nameservers and glue records step‑by‑step is a good companion to your IPv6 rollout.

Web Hosting: Preserve the Required Client Paths

A dual-stack public endpoint is an option when both IPv4 and IPv6 clients need direct access. The public edge and backend can use different families:

• Your site keeps its existing IPv4 address and A record.
• You configure an IPv6 address on the same virtual host or server block.
• You test the IPv6 hostname, TLS and application path externally before adding a matching AAAA record in DNS.
• Test certificate renewal validation too. An incorrect AAAA endpoint can cause Let’s Encrypt HTTP-01 validation to fail despite working IPv4; a wrong challenge response does not trigger IPv4 retry.
• Logging, rate-limiting and security rules are updated to cover both address families.

This approach is exactly what we describe in more detail in our article about building a no‑drama dual‑stack IPv6 playbook. You do not need to switch off IPv4 or run IPv6‑only to benefit from the increasing share of IPv6‑capable users.

VPS and Dedicated Servers: Clean Network Design from Day One

When you provision a new VPS or dedicated server, the best time to incorporate IPv6 is at the very beginning, before you have a lot of legacy configuration. That is why we strongly recommend treating IPv6 as part of your standard build checklist: assign IPv6 addresses, configure firewalls, and test connectivity in your automation or Ansible playbooks.

If you want a hands‑on walkthrough, our detailed guide on IPv6 setup and configuration for your VPS server shows how to configure addresses, routes and firewall rules on popular Linux distributions, with the actual interface, routing and service details adapted to your provider and operating system.

Email: Deliverability and Reputation in an IPv6 World

Email sending and receiving are separate IPv6 decisions. Confirm the specific recipient’s support and policy, the sending address’s PTR and matching forward DNS, and a valid HELO/EHLO identity. SPF authorizes the sending IP for the applicable MAIL FROM or HELO domain; DKIM signs messages and DMARC evaluates alignment with the visible From domain. These are different roles, not one record that simply “covers IPv6”.

We have a dedicated article on email deliverability over IPv6, including PTR, HELO, SPF and blocklists that walks through real‑world configurations. Monitor actual SMTP replies, delivery failures and recipient acceptance during a separate pilot; correct DNS and authentication do not guarantee inbox placement.

Designing a Realistic IPv6 Adoption Roadmap

Use a phased plan matched to the service dependencies and maintenance windows. Each phase needs an owner, expected result, actual evidence and a recovery path. A low-impact pilot should still represent the protocols and user flows that will run in production.

Step 1: Inventory and Traffic Analysis

Start with visibility. Identify:

• Which domains and subdomains you control.
• Which services they point to (web, API, mail, VPN, admin panels).
• Where those services are hosted (shared hosting, VPS, dedicated, colocation).

Confirm IPv6 addressing, routing and support for the exact hosting product and location. Existing IPv4-only service logs cannot reveal how many visitors could use IPv6. After a validated dual-stack pilot, measure observed request or connection share at a defined collection point; behind a CDN, client-to-edge and edge-to-origin families can differ. For public source definitions, see IPv6 adoption metrics and deployment choices.

Step 2: Enable IPv6 in a Controlled Pilot

Pick a low‑risk but representative property for your first pilot: a smaller public site, a staging environment or an internal application with predictable users. Prepare addressing, routing, listeners, security and per-family monitoring; test the intended hostname externally over IPv6, then publish AAAA.

During this pilot, you want to verify:

• Firewall rules and security policies work as expected for IPv6 traffic.
• Logs, metrics and alerting correctly capture and display IPv6 addresses.
• Any IP‑based access control lists (ACLs) or rate limits are updated for IPv6.

Once you are comfortable, you can reuse this configuration as a template for other services.

Step 3: Roll Out IPv6 to Core Web Properties

Expand to your main websites and APIs once the pilot meets the agreed criteria. Validate login, checkout, callbacks and other critical flows as well as the first page. Record IPv6 share from your own filtered dataset and interval; there is no expected 20–40% result or requirement to follow a global chart.

This is also a good moment to think about overall architecture: if you are expecting strong growth, you may wish to revisit your hosting model. Our comparison of dedicated servers vs VPS and which one fits your business can help you align IPv6 adoption with broader capacity planning.

Step 4: Extend to Email, Admin Panels and Internal Services

After your main public‑facing endpoints are stable on dual‑stack, extend IPv6 to:

• Mail servers (with proper PTR, HELO, SPF/DKIM/DMARC).
• VPN endpoints and remote access gateways.
• Admin panels, monitoring dashboards and internal APIs.

At this stage, you can also consider using IPv6 internally between services hosted on multiple VPS or dedicated servers, while still presenting dual-stack endpoints externally. This may reduce address-overlap or NAT complexity in a suitable design, but discovery, security, telemetry and recovery still need testing.

If an internal segment becomes IPv6-only, design access to IPv4-only dependencies separately. NAT64/DNS64 can provide outbound access for compatible applications; ordinary outbound translation does not automatically let IPv4 visitors reach an IPv6-only website. Keep a dual-stack proxy or another explicitly designed ingress path where those visitors require access. Test applications using IPv4 address literals and the DNS64/DNSSEC validation arrangement rather than assuming universal compatibility.

Step 5: Review, Document and Automate

Finally, treat IPv6 as a first‑class citizen in your documentation and automation:

• Update onboarding checklists so new hostnames receive AAAA only when their IPv6 endpoint and protection have passed validation; retain the required IPv4 records.
• Extend configuration management templates (Ansible, Terraform, etc.) to handle IPv6 interfaces by default.
• Train your team to read and work with IPv6 addresses comfortably in logs and firewall rules.

Our article on accelerating IPv6 adoption without drama provides a companion process for organizing a staged rollout.

Planning Examples for Hosting Environments

The following scenarios are planning examples, not reports of DCHost customer deployments or measured results. They show how the same readiness checks apply to different service boundaries.

Scenario 1: Growing E‑Commerce Site on a Single VPS

Consider an online store running WooCommerce or another PHP platform with mobile and international visitors. Suppose it receives reports of slow checkout from particular networks. First collect connection, application and server evidence; those symptoms do not by themselves identify IPv4 or missing IPv6 as the cause.

A controlled comparison can include:

• Enabling dual‑stack IPv6 on the existing VPS.
• Testing critical user flows and IPv6 protection before adding AAAA for validated hostnames.
• Monitoring latency and error rates per IP family.

Keep cache state, PHP-FPM and database work separate in the comparison so their effects are not credited to the IP family. Evaluate timing and failures over both paths from comparable networks, then decide whether to expand IPv6, repair a route or address an application bottleneck.

Scenario 2: Multi‑Site Agency Hosting on Reseller or Multi‑VPS Architecture

Consider an agency hosting multiple client sites on reseller plans or VPS nodes. A repeatable playbook can cover common settings, but each site still needs the correct DNS, certificate, application checks and management permissions.

For the servers and products that support the design, a reusable template can:

• Define a template for vhosts that includes both IPv4 and IPv6 bindings.
• Roll out AAAA records through DNS workflows only after each corresponding endpoint passes validation.
• Update log aggregation, WAF rules and security headers to treat IPv6 as normal.

When combined with the techniques in our guide on access management for agencies on hosting panels, this creates a consistent and maintainable IPv6 posture across many client projects.

Scenario 3: Colocation or Hybrid Infrastructure with Strict Compliance

Consider a colocation or hybrid setup with a defined contractual or regulatory requirement. Record the actual requirement, assets in scope and acceptance evidence before selecting the network design; an adoption trend does not determine compliance.

The design review can cover:

• Segmentation: separate IPv6 segments for public, DMZ and internal traffic.
• Consistent firewall templates for both IPv4 and IPv6.
• Documented DR plans, so disaster recovery and failover handle IPv6 routes and addresses cleanly.

A documented address plan can help associate services with network events, but an address is not an authenticated user identity and may change. Keep asset ownership, authentication and event records appropriate to the actual investigation and compliance requirements.

Key Metrics to Track as IPv6 Adoption Grows

Define the observation point, interval, filters and denominator for each measure. Keep connection failures and application outcomes alongside traffic share so increased volume does not conceal a broken path.

1. IPv6 Traffic Share

For an HTTP request share, divide observed IPv6 requests by all observed IPv4 and IPv6 requests in the same filtered edge dataset and period. Label it as requests, not people or devices. Origin logs behind a proxy may show a different family; trust forwarded client data only from configured proxies. Failed connections that never deliver an HTTP request are absent from this count, and the result need not follow a global trend.

2. Error Rates and Latency by IP Family

Monitor 4xx/5xx error rates, TLS handshake failures and latency distributions separately for IPv4 and IPv6. If IPv6 metrics look significantly worse, you may have routing issues, misconfigured firewalls or overloaded IPv6 paths in front of your servers.

3. Email Deliverability Over IPv6

For mail, track which providers are accepting your emails over IPv6, and keep an eye on bounce messages, spam folder placement and blocklist status. If you are not sure how to interpret these signals, our playbook for recovering email sender reputation and IP warm‑up is a good complement to your IPv6 deliverability work.

4. Configuration Drift Between IPv4 and IPv6

Finally, periodically review your configuration to ensure IPv4 and IPv6 behave consistently. Common pitfalls include:

• WAF or rate‑limiting rules applied only on IPv4 listeners.
• Geo‑blocking or access control lists missing IPv6 ranges.
• Monitoring checks pinging only IPv4 addresses.

Run those checks when listeners, DNS, proxies, security policies or application dependencies change. Maintain explicit IPv6 probes even when a dual-stack browser appears healthy through IPv4 fallback. For DNS rollback, account for answers cached under the previous TTL and for existing connections; keep previously advertised endpoints available where possible.

Close Readiness Gaps Before Expanding

Set rollout pace from the gaps in your own inventory, representative tests and business requirements. A high public adoption figure does not approve a service change; a lower one does not establish that your required users lack IPv6.

If your sites and applications still run IPv4‑only, we recommend treating IPv6 as a near‑term strategic task rather than a someday item. Start with a clear inventory, then move to small, low‑risk pilots. From there, roll out dual‑stack support to your core sites, APIs and email infrastructure. Use concrete, measurable metrics—traffic share, latency, error rates—to validate that your deployment is working well.

For DCHost or another provider, confirm IPv6 availability, assigned addressing, routing, protection and management responsibilities for the product and location you will use. Keep the required IPv4 path, name an owner for unresolved dependencies, and document the evidence needed for the next stage. That produces a practical readiness decision rather than a provider-wide assumption.