Selection Guide · Networking and Wi-Fi
IPv6 Transition: Dual Stack, IPv6-Only and NAT64 Selection
Dual stack operates IPv4 and IPv6 together; IPv6-only clients can access IPv4 destinations through translation. Address quantity alone does not decide. DNS, literal-IP application…
Technical review:
Architecture and operating model
Dual stack operates IPv4 and IPv6 together; IPv6-only clients can access IPv4 destinations through translation. Address quantity alone does not decide. DNS, literal-IP application behavior, firewall visibility and operational monitoring matter.
Absence of IPv6 NAT does not imply open access; stateful policy is still required. Test neighbor discovery, router advertisements, DHCPv6 and DNS distribution per endpoint OS. Do not assume IPv4 firewall rules automatically cover IPv6.
- 1Application inventory
- 2Address and DNS plan
- 3Pilot access/security
- 4Transition and monitoring
Design parameters
- Application compatibility
- Test hostname and literal-address connections separately; NAT64/DNS64 does not repair every legacy application.
- Address plan
- Evaluate ISP delegation, site prefixes and per-subnet /64 design with growth and renumbering.
- Security visibility
- Verify IPv6 ACL, DNS and session logs reach central monitoring.
Platform implementation
Service names are reference points. Scope, defaults, region availability and operating requirements differ; they are not interchangeable guarantees.
| Model | Suitable case | Operational burden |
|---|---|---|
| Dual stack | Mixed legacy/new applications | Two address families and policies |
| IPv6-only + NAT64 | Managed, validated clients | DNS64/translation and application tests |
| Staged IPv6 | Restricted initial pilot | Temporary dual-environment coordination |
Worked example
Start a dual-stack pilot with one user VLAN and two applications across three sites. Measure AAAA resolution, IPv6 path failure, IPv4 fallback and unauthorized IPv6 access separately. If a critical legacy application uses literal IPv4, plan an exception before forcing translation.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Some sites open slowly | Broken IPv6 path and delayed fallback. | Compare A/AAAA answers and latency in both families. |
| IPv4 blocked but IPv6 allowed | Missing IPv6 security policy. | Run the same negative access test in both protocols. |
Acceptance checks
- Verify address allocation.
- Test RA/DHCPv6 behavior.
- Verify AAAA records in the pilot.
- Test firewall policy in both families.
- Identify literal-IPv4 applications.
- Document rollback and monitoring.
Related concepts
Layer 2 and Layer 3 boundaries
A VLAN creates a separate broadcast domain; routing and access policies govern communication between VLANs. Review trunk allowed lists, access-port assignment and gateway placement together. A network diagram should show where packets are routed and filtered, not merely which cables connect devices. Sharing a switch does not require sharing privileges. When access fails, confirm VLAN and addressing first, then gateway, route and policy matching.
DNS caching and dependencies
DNS results depend on client and recursive-resolver caches as well as authoritative data. Changing a TTL does not retroactively shorten already cached answers. A/AAAA, CNAME, MX and TXT records serve different purposes. Test internal and external views separately; split DNS may intentionally return different results. Record resolver, response type, TTL and query time when troubleshooting. Successful access by IP address alone does not prove correct DNS configuration.
IT/OT security zones
A zone groups assets with similar operational and security requirements; communications between zones should traverse controlled conduits. An accessible OT device is not necessarily safe to scan or update. Control latency, safety, vendor support and maintenance windows influence decisions. Observe actual PLC and SCADA flows rather than copying IT policies unchanged. Define identity, duration, approval and logging requirements for remote support, and coordinate active tests and cutovers with production owners.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.