Ga naar de inhoud 
An IPv6 hosting migration starts with the services that must keep working: customer logins, API requests, payment callbacks, backups, and administrative access. Adding an IPv6 address is one step. Keeping those services reachable is the deployment goal.
We use this checklist to connect application requirements with infrastructure decisions. We plan IPv6 support across each traffic path, retain IPv4 where it remains necessary, and define the evidence required before a wider rollout.
Bring the resulting requirements to Atal Networks to discuss a suitable hosting and routing setup. Confirm capabilities for your chosen service and location before committing to the design.
1. Choose an IPv6-First Architecture
IPv6-first means we plan for IPv6 support from the start. Dual-stack means a network or service supports both IPv4 and IPv6. Neither term means that every application dependency already works over IPv6.
We separate four paths: customers to the public endpoint, the public endpoint to the application server, applications to external services, and administrators to management systems.
| Architecture | Suitable use | Check before deployment |
|---|---|---|
| Dual-stack endpoint and origin | Direct access over both address families | Routing, listeners, security, and monitoring for each family |
| Dual-stack proxy with IPv4 origin | Public IPv6 access before origin migration | Proxy protocol support and client-address handling |
| Dual-stack proxy with IPv6-only origin | Removing IPv4 from the origin tier | Backend connectivity, health checks, dependencies, and management |
| IPv6-only workload with outbound translation | Access to IPv4-only external services | Application compatibility, translation capacity, and recovery |
A content delivery network may accept IPv6 connections while reaching the origin over IPv4. Public IPv6 access therefore does not prove that the origin supports IPv6. Cloudflare documents separate client-facing and origin-connection behavior.[1]
We choose the architecture per service rather than assuming the entire platform must change at once.
2. Inventory Applications and Dependencies
Our inventory needs to explain what each service connects to, in both directions.
Include websites, APIs, databases, queues, identity providers, payment systems, webhooks, email, package repositories, license servers, backups, monitoring, and deployment tools.
Check for hardcoded IPv4 addresses, IPv4-only application libraries, IP-based allowlists, and address fields that cannot store IPv6. Review container networking and VPN access as well as the host operating system.
Use a record like this for each dependency:
| Field | Example entry |
|---|---|
| Service | Customer API |
| Traffic direction | Outbound to billing provider |
| Current requirement | Provider accepts an IPv4 source allowlist |
| Owner | Application team |
| Acceptance test | Successful request from the approved source address |
| Temporary decision | Retain controlled IPv4 egress |
| Review trigger | Billing provider adds supported IPv6 access |
This is an illustrative record, not a test result. The completed inventory gives us a clear list of blockers, owners, and temporary IPv4 requirements.
3. Plan Addresses Around the Hosting Service
An IPv6 address assigned to a server and a prefix routed to a customer network serve different purposes. We confirm which arrangement the workload needs before selecting infrastructure.
Ask the provider to confirm the address or prefix allocation, gateway, routing method, reverse-DNS control, and any restrictions on using addresses behind a virtual machine or router.
For ordinary LANs using stateless address autoconfiguration, /64 is the usual subnet size. That does not mean every VPS includes a /64, or that host routes and specialized router links use the same design.
We record allocations by location, environment, application, and tenant in an IP address management system. Reserve room for growth and define stable addresses for services and outbound allowlists.
Follow the provider’s instructions for static settings, router advertisements, DHCPv6, and default routes. Do not assume DHCPv6 alone supplies the default gateway. Record renumbering responsibilities if the hosting arrangement changes.
4. Prepare DNS Before Publishing AAAA Records
An A record identifies an IPv4 address. An AAAA record identifies an IPv6 address. Neither record converts traffic between the two protocols.
We publish AAAA records after confirming that the intended endpoint accepts IPv6 traffic, presents the correct TLS certificate, completes application requests, and applies the required security controls.
Keep A records wherever IPv4 access remains part of the design. The protocol used to query DNS does not determine whether the answer contains A or AAAA records.
Before release, check:
- Public and internal hostname resolution.
- Direct versus CDN-proxied DNS behavior.
- TLS hostname coverage and certificate-renewal paths.
- Reverse DNS where the service requires it.
- The current TTL and proposed rollback timing.
Reduce the time-to-live, or TTL, ahead of the change and allow the previous TTL to expire. Cached answers, cached missing-record responses, and existing connections can delay the effect of later DNS changes.
5. Test Operating Systems and Applications
We check persistent addresses, default routes, DNS resolution, application listeners, and firewall rules. Repeat the checks after reboot and after automated deployment.
An application listening on IPv4 may need a separate IPv6 listener. Binding to :: also requires review because operating systems and socket settings differ in how they handle IPv4 connections through that listener.
Test IPv4 and IPv6 separately. A browser can complete a request over one family while the other has failed. The Happy Eyeballs connection method reduces user-visible delays by trying available addresses, which can hide a faulty path.[2]
We test complete workflows: login, API authentication, uploads, callbacks, database access, and scheduled jobs. A successful ping confirms much less than a successful customer transaction.
For server-level implementation checks, use our IPv6 deployment guide for VPS and dedicated servers.
6. Review Load Balancers, Firewalls, and Access Controls
A load balancer may support IPv6 on its public interface while using a different address family for backend connections or health checks. We confirm each function separately.
Review network and host firewalls, web application firewall rules, DDoS coverage, administrative restrictions, VPN access, and direct access to the origin. IPv4 rules do not automatically create the required IPv6 policy on every platform.
IPv6 does not encrypt application traffic or replace access controls. Keep TLS, authentication, and service restrictions in place.
Allow the ICMPv6 messages required by the network design. Blocking all ICMPv6 can disrupt Neighbor Discovery or prevent Packet Too Big messages from reaching hosts, causing larger transfers to fail. RFC 4890 provides filtering guidance.[3]
Test large uploads and responses. Confirm that rate limits accept IPv6 addresses and that the application trusts client-address headers only from approved proxies.
7. Monitor IPv6 as a Separate Service Path
We track IPv4 and IPv6 availability, connection failures, TLS errors, application errors, and latency separately. A combined success rate can hide a problem affecting the smaller traffic group.
Use external probes from networks relevant to your customers. Separate client-to-CDN measurements from CDN-to-origin measurements so the dashboard shows the path actually tested.
Check that logs, analytics, security tools, and databases store complete IPv6 addresses. Avoid fields sized only for IPv4 and parsing code that splits an address at every colon.
Assign alerts to an owner who can inspect DNS, routes, application listeners, and security controls. Test alert delivery before public rollout. Low IPv6 traffic alone is not proof of failure, but an unexpected drop deserves investigation.
8. Keep IPv4 Where Compatibility Requires It
We remove IPv4 only after identifying the users and dependencies that still need it.
| Remaining requirement | Possible approach | Decision to confirm |
|---|---|---|
| IPv4-only customers | Dual-stack public endpoint or suitable proxy | Protocol support and public access |
| IPv4-only external API | NAT64/DNS64 where supported | Application and resolver compatibility |
| IPv4-only management tool | Restricted IPv4 management path | Access ownership and replacement plan |
| IPv4 source allowlist | Controlled IPv4 egress | Stable source address and operating cost |
NAT64 translates traffic between address families. DNS64 can create IPv6 answers for IPv4-only destinations so compatible IPv6 clients can reach them through that translation path.
This arrangement does not solve every application with embedded IPv4 addresses. DNSSEC checks also need to fit the resolver design. We test the actual application and resolver combination rather than disabling security checks to make it work.[4]
Outbound translation does not, by itself, provide general inbound access for IPv4-only customers.
Compare the full operating cost: retained IPv4 addresses, proxies or translators, data transfer, monitoring, support, and engineering time. Removing addresses from one tier does not guarantee a lower total bill.
9. Confirm ASN and BGP Requirements
A server using provider-assigned IPv6 addresses normally does not require you to operate BGP or obtain your own autonomous system number, or ASN.
Customer-controlled routing needs a separate plan. For a design involving your own prefixes or multiple upstream providers, document:
- The ASN and prefixes you intend to announce.
- Address ownership or authorization.
- Provider-supported announcement lengths and filters.
- Internet Routing Registry records where required.
- Route Origin Authorizations matching the intended origin ASN.
- Responsibility for routing changes and incidents.
A Route Origin Authorization, or ROA, states which ASN may originate a prefix and the permitted maximum prefix length. Check IPv6 routing records and policy separately from IPv4.
Use our IPv4, IPv6, and ASN resource page to frame the discussion, then confirm the requirements for your deployment.
10. Stage the Rollout and Prepare Recovery
We approve each stage using recorded evidence. Set acceptable error rates and response times against the application’s existing service targets.
| Stage | Evidence needed to proceed | Reason to stop |
|---|---|---|
| Baseline | Dependencies, owners, current behavior, and recovery access recorded | A critical requirement remains unknown |
| Lab | Network and complete application workflows pass | A transaction or security control fails |
| Pilot | Selected service meets agreed targets | Errors or latency exceed agreed limits |
| Wider rollout | Monitoring and support cover the added scope | Customer impact or unexplained failures |
| IPv4 retirement review | Required access paths have approved replacements | A necessary IPv4 dependency remains |
Use a controlled test hostname or selected service for the pilot. DNS-based traffic distribution does not guarantee an exact percentage of users because resolvers and clients cache answers.
The test set should include login, uploads, webhooks, deployments, backups, restoration, management access, and failover. Test from relevant external networks as well as inside the hosting environment.
Write the recovery procedure before publishing DNS changes. Record who can restore prior proxy settings, routes, firewall policy, and application configuration. Keep emergency console access available.
Removing an AAAA record does not immediately remove cached copies or end existing connections. Where safe, keep the affected endpoint serviceable while traffic drains. Do not disable IPv6 across the platform without checking which internal services now depend on it.
11. Complete the Operational Handoff
We complete security approval before public rollout and keep the supporting records in one maintained runbook.
That runbook should contain the architecture, address plan, DNS records, routing policy, security decisions, test results, monitoring, incident contacts, and rollback steps. Include backup-restoration checks and emergency access through the paths that will remain available.
| Responsibility | Required agreement |
|---|---|
| Guest operating system and applications | Named owner for configuration and patching |
| DNS and public endpoints | Owner authorized to publish and reverse changes |
| Routing and network controls | Clear customer/provider boundary |
| Monitoring and incident response | Alert recipient and response scope |
| Backups and recovery | Retention, restore access, and test ownership |
Hosting alone does not define ownership of every task. Confirm the support scope in writing and review temporary IPv4 exceptions after dependency or application changes.
12. Bring a Deployment Brief to Atal Networks
We can make the infrastructure discussion more specific by starting with your workload and migration requirements.
Prepare the following:
- Applications, operating systems, and deployment methods.
- User locations and expected traffic.
- Current IPv4 addresses and remaining IPv4 dependencies.
- DNS, CDN, load-balancer, and firewall arrangements.
- Required IPv6 addresses or routed prefixes.
- ASN and prefixes, if customer routing applies.
- Security controls and operational responsibilities.
- Maintenance window, acceptance tests, and rollback limits.
Ask us to confirm IPv6 availability for the selected service and location, allocation and routing details, reverse DNS, protection scope, and any requested BGP support. Treat proxy, translation, and managed-service functions as requirements to discuss until their availability and terms are confirmed.
Discuss your applications, current address usage, DNS, ASN, routing, and migration requirements with Atal Networks. Share the deployment brief through our contact page to discuss suitable options.
IPv6 Hosting Migration FAQs
Can we migrate to IPv6 without removing IPv4?
Yes. We can use dual-stack services during migration and retain IPv4 for users or dependencies that need it. Removing IPv4 requires a separate compatibility review.
Does an AAAA record make our application IPv6-ready?
No. It publishes an IPv6 destination. Routing, listeners, TLS, security controls, and application workflows must work at that destination before release.
Can IPv4-only users reach an IPv6-only origin?
They can through a suitable IPv4-capable frontend that reaches the origin over IPv6. Confirm that the proxy supports the application’s protocols and connection behavior.
Do we need an ASN for IPv6 hosting?
Usually not for a server using provider-assigned addresses. An ASN becomes relevant for customer-controlled routing designs, subject to provider requirements.
Can we reverse an IPv6 DNS change immediately?
We can change the authoritative DNS record promptly, but clients may retain cached answers and existing connections. Our rollback plan must account for both.