Google just crossed 50% of traffic served over IPv6. If you’re still IPv4‑only, you’re choosing higher tail latency, CGNAT fragility, and brittle allowlists for half your users—especially on mobile. IPv6 isn’t a vanity upgrade anymore; it’s a reliability and cost decision. The good news: you can roll it out safely in weeks, not quarters, if you scope it correctly.
What 50% IPv6 Actually Means for Your Roadmap
On consumer networks (and in Brazil in particular), IPv6 is now the default path. Carriers prefer it because it reduces NAT contention and operational pain. For you, that translates to three tangible effects:
- Lower tail latency on mobile: Happy Eyeballs (RFC 8305) will race A vs AAAA. Where carriers optimize v6, you’ll see 5–25 ms improvements in connect times and fewer NAT timeouts under load.
- Fewer mysterious outages: CGNAT failure modes (state exhaustion, asymmetric routing) disproportionately hit IPv4. Dual‑stack gives the client a second, often cleaner path.
- Security and ops consistency pressure: If your WAF, rate‑limits, logs, and allowlists don’t fully support IPv6, you’ve created a bypass path or a blind spot. Attackers notice first.
Add the economics: public IPv4 addresses have traded around $45–$60 each in recent years, and monthly rentals often land at $1–$2 per address. Meanwhile, every major CDN and cloud gives you IPv6 at no premium. Staying IPv4‑only is a tax you no longer need to pay.
Do You Need IPv6 This Quarter? A Simple Decision Framework
Prioritize dual‑stack in the next 90 days if two or more are true:
- Mobile >50% of traffic or significant LATAM/Asia footprint. Brazil’s consumer ISPs have been v6‑forward for years.
- Your app is latency sensitive: live data, streaming, real‑time collaboration, token‑streaming AI responses.
- You do IP‑based controls: WAF rules, rate‑limits, abuse heuristics, or partner allowlists keyed by IP.
- You’ve hit CGNAT pain: user complaints that vanish over Wi‑Fi, spikes in 522/524 (CDN) or 502/504 (origin) during traffic peaks.
If you’re pure B2B behind corporate VPNs, v6 may be lower urgency—but you’ll still want parity before 2027 as more enterprise networks flip dual‑stack by default.
Where IPv6 Bites: Architecture and Data Model Impact
1) DNS and Edge
- CDN support: CloudFront, Fastly, and Cloudflare have supported AAAA at the edge for years. Enable v6 per distribution/zone.
- Avoid origin bypass: If your CDN/WAF is your shield, ensure there’s no direct AAAA to origin that skips it. Lock security groups, firewall rules, and DNS so only the CDN can reach the origin over both v4 and v6.
2) Load Balancers and Origins
- AWS: ALB and NLB support IPv6 for internet‑facing LBs; Route 53 supports AAAA alias. Put S3 websites behind CloudFront to get IPv6.
- GCP/Azure: Global HTTP(S) LBs and Front Door support IPv6. Validate health check parity for both families.
3) Kubernetes and Services
- Dual‑stack K8s has been stable for several releases. EKS/GKE/AKS all support it with dual‑stack CNI.
- Service meshes: Confirm Envoy/NGINX Ingress and your mesh (Istio/Linkerd) advertise and route v6 correctly. Test mTLS on both families.
4) Data Model and Logging
- Stop storing IPs in VARCHAR(15). Use Postgres inet/cidr, VARBINARY(16), or at least VARCHAR(39) with canonical formatting (RFC 5952).
- Parsing: X‑Forwarded‑For and similar headers will include IPv6 and potentially multiple addresses. Your log pipeline and SIEM must parse both families without truncation.
5) Rate‑Limiting and Abuse Controls
- Per‑IP is weaker on v6. Privacy extensions and carrier allocations mean a single user may rotate /128s. Use /64 aggregation or combine IP with account, cookie, device, and behavior signals.
- Quota math: Revisit limits keyed purely by IP to avoid abuser headroom and false positives on legitimate rotations.
6) Outbound Calls and Allowlists
- Egress: If partners allowlist your IPs, keep v4 egress stable. Add v6 egress only after confirming the partner supports it—and that they won’t reject your traffic due to missing AAAA on their side.
- Client libraries: Rip out IPv4 literals. Use getaddrinfo and hostname‑first resolution everywhere. URLs with IPv6 literals must be bracketed (example: http://[2001:db8::1]/path).
Your 4‑Stage Dual‑Stack Rollout (With Kill Switches)
This plan keeps risk at the edge until your internals are ready. Each stage has a kill switch and clear exit criteria.
Stage 1: Edge‑Only IPv6 (1–2 weeks)
- Enable IPv6 on the CDN, keep origin IPv4‑only. The CDN terminates v6 and forwards to your origin over v4.
- Expose AAAA records in DNS for public hostnames behind the CDN.
- Kill switch: Disable AAAA at the CDN and remove AAAA in DNS. Rollback time: minutes.
- Success metric: ≥30% of edge requests over v6 with no new 4xx/5xx deltas and P95 connect time improvement ≥5 ms on mobile networks.
Stage 2: Dual‑Stack the Load Balancers (1–3 weeks)
- Enable IPv6 on ALB/NLB and security groups. Keep instances and pods reachable over v4 while you validate.
- Health checks and WAF: Ensure L7 health checks work for both families; confirm WAF sees the real client IP via CDN headers.
- Kill switch: Remove AAAA at Route 53/Cloud DNS; keep CDN on v4 pass‑through.
- Success metric: No increase in 502/504 from LBs; origin logs show real client IPs (not just CDN PoP) when desired.
Stage 3: Service‑to‑Service (2–4 weeks)
- Turn on K8s dual‑stack and mesh support in one non‑critical namespace. Validate DNS64/Happy Eyeballs behavior inside the cluster.
- Library sweep: Replace IPv4‑only network code, upgrade DNS resolvers, and fix any URL construction issues with IPv6 literals.
- Kill switch: Namespace‑level or service‑level feature flag to force IPv4 upstreams.
- Success metric: Services can dial both families; no regression in connection churn or error budgets.
Stage 4: Egress and Partners (2–6 weeks, parallel)
- Stabilize outbound NAT/egress with known v6 addresses. Document them for partners; don’t remove v4 until all partner allowlists take v6.
- Mail, payments, analytics: Validate each vendor’s v6 policy. Some still prefer v4 for SMTP acceptance; pick your battles.
- Kill switch: Route outbound through v4 NAT gateway; keep dual paths pre‑configured.
Security Parity or Don’t Ship
Most IPv6 risks are really “configuration drift” risks. Fix them before adding AAAA.
- WAF and DDoS coverage: Confirm your provider mitigates v6 volumetric and L7 attacks at the same levels as v4. Read the fine print.
- Firewall rules: Update security groups and network ACLs to include IPv6. Don’t leave a wide‑open ::/0 while your v4 rules are tight.
- Rate‑limits and fraud: Move away from pure /128 limits. Aggregate to /64 where appropriate, and mix user/account/device signals.
- Logging and forensics: Ensure SIEM, threat intel feeds, and custom dashboards handle IPv6 without truncation or mis‑parsing. Train on new indicators: brackets in URLs, compressed notation nuances.
Observability: Measure by Address Family
Treat IPv6 as a first‑class dimension in your SLOs and dashboards for at least one quarter.
- Break out metrics by v4 vs v6 for connect time, TLS handshake, P50/P95/P99 latency, error rates, and retry counts.
- Track adoption by country and network: Use your CDN logs to see where v6 is dominant (Brazil, US mobile) and where it lags. This guides regional rollouts.
- Alerting: Dedicated alerts for v6 regression prevent silent degradations masked by healthy v4 traffic.
Data Model Cleanup You Can’t Skip
- Schema: Migrate IP columns to Postgres inet/cidr or VARBINARY(16). Backfill and dual‑write for one release before cutting over.
- Indexing: Create indexes that support range queries (e.g., inet_ops) so /64 aggregation and abuse heuristics are fast.
- Serialization: Standardize on canonical text form for logs (RFC 5952). Consistency matters for deduplication and joins.
Common Failure Modes (So You Don’t Learn Them the Hard Way)
- Origin bypass: Publishing AAAA on an origin hostname that isn’t locked to the CDN/WAF path. Fix with private origins and strict security groups.
- Hard‑coded IPv4 in config or code. Grep for dotted quads; add linting to block merges that introduce them.
- URL parsing bugs: Clients forget brackets around IPv6 literals in URLs, breaking HTTP Host headers and TLS SNI.
- Truncated logs: 39‑char IPv6 addresses (or comma‑separated XFF chains) get sliced in 32‑char columns and break analytics.
- Unbalanced limits: Per‑IP rate limits allow abusers unlimited tries over rotating /128s, while legitimate users get throttled behind corporate /64s.
How Long Will This Take? What Will It Cost?
For a typical SaaS with CDN and managed LBs:
- Stage 1 (edge‑only): 1–2 weeks, 1 engineer, negligible infra cost.
- Stage 2 (LBs): 1–3 weeks, 1–2 engineers, changes to security groups and health checks.
- Stage 3 (service‑to‑service): 2–4 weeks, 2 engineers, some library upgrades and mesh validation.
- Stage 4 (egress): 2–6 weeks, mostly partner coordination and policy updates.
Call it 4–10 engineer‑weeks for a clean dual‑stack path to the edge and origin, plus a quarter to bake it into internal services. Dual‑stack adds a modest operational overhead (think 5–10% more metrics, rules, and tests) that fades as your tooling catches up.
Testing: Don’t Ship Without These Checks
- IPv6‑only network: Set up NAT64/DNS64 in a test VPC and on a local Wi‑Fi SSID. Apple has required IPv6‑only app testing for years; use the same pattern for your backends.
- Happy Eyeballs behavior: Force both address families to validate fallback works and to quantify the latency delta you’re actually getting.
- Abuse harness: Simulate rotating /128s and large /64 allocations to test your rate‑limits and WAF rules.
- End‑to‑end traces: Confirm client IP attribution and geolocation work with IPv6 in your analytics and fraud models.
Vendor Readiness Checklist
- CDN/WAF: IPv6 enabled, DDoS parity, logs include v6, no origin bypass.
- DNS: AAAA with health‑checked failover. Weighted routing lets you canary v6 by region (e.g., 10% AAAA in one POP).
- Load balancers: Dual‑stack listeners, v6 security groups, matching health checks.
- Kubernetes: Cluster and CNI dual‑stack, service/ingress support, mesh policy parity.
- Observability: Log shipper and SIEM parse IPv6; dashboards segment by family.
- Third parties: Payments, auth, analytics, email—document who supports v6 and who must remain v4‑only for now.
Why This Matters for Nearshore Teams
Brazilian carriers have been ahead of many markets on IPv6 deployment. A nearshore team in Brazil can exercise real‑world IPv6 paths daily, not synthetic lab setups. That means faster feedback on latency changes, error patterns, and WAF behavior on networks where your growth is coming from. Expect 6–8 hours of timezone overlap with US teams and 20–30% lower cost than equivalent US staff to run this migration without slowing product velocity.
Bottom Line
Half your users are already choosing IPv6 when you offer it. Dual‑stack won’t win you a press release, but it will make your app feel faster and more reliable where it counts—on the networks your customers actually use. Roll it out at the edge first, secure it like v4, fix your data model, and measure it like a first‑class citizen.
Key Takeaways
- Google reports ~50% of traffic over IPv6; mobile users and Brazil skew even higher. IPv6 is now table stakes.
- Start at the CDN: enable IPv6 and AAAA with a fast kill switch; keep origins IPv4 until you harden.
- Security parity is non‑negotiable: WAF, firewall rules, and DDoS must match v4 capabilities.
- Fix your data model: use inet/cidr or 16‑byte storage; stop storing IPs in VARCHAR(15).
- Rate‑limit smarter: combine account/device signals; aggregate IPv6 by /64 where appropriate.
- Measure by family: create dedicated v4 vs v6 SLOs and alerts for at least one quarter.
- Plan 4–10 engineer‑weeks for edge and origin dual‑stack; a quarter to complete internal adoption.
- Nearshore teams in Brazil can validate real‑world IPv6 paths quickly and cost‑effectively.