IPv6 for Internet Service Providers

IPv4 is exhausted. CGNAT buys time but does not solve the structural problem. Native IPv6 with dual stack is the path — and it is simpler to deploy than most ISPs expect.

Why deploy IPv6 now

LACNIC exhausted the public IPv4 pool in 2014. Buying IPv4 blocks today costs thousands of dollars per /24. CGNAT scales the problem but adds complexity, compliance risk and degraded subscriber experience for some applications. IPv6 eliminates all of that: every subscriber gets a real routable prefix with no shared translation.

Major content providers — Google, Netflix, Meta, Cloudflare — have had IPv6 enabled for years. An ISP with native IPv6 delivers better performance for this traffic and avoids the latency introduced by CGNAT translation.

Getting an IPv6 block from LACNIC

To announce your own IPv6 prefixes, you need a block delegated by LACNIC. We help prepare the technical documentation required for the submission — the formal LACNIC submission itself must be made by the ISP's technical admin, as it involves account credentials.

  • Assessment of the appropriate block size for your current base and growth projection (/32, /28 or larger)
  • Technical documentation for the LACNIC request
  • ROA registration in RPKI immediately after delegation
  • Announcement configuration on the border router and validation with BGP peers

Dual-stack deployment: IPv4 + IPv6 in parallel

The recommended approach is dual stack: each subscriber gets both an IPv4 address (public or behind CGNAT) and an IPv6 prefix. Content reachable via IPv6 is loaded directly; the rest falls back to IPv4. There is no disruption to existing subscribers.

  • Dual-stack configuration on the B-RAS/BNG (Huawei NE8000, Juniper MX, MikroTik CCR)
  • DHCPv6-PD (Prefix Delegation) for distributing /56 or /60 per subscriber
  • SLAAC and RA configuration for self-configuration on subscriber-side equipment
  • IPv6 filtering policy: ICMPv6 types required for ND, MTU discovery and RS/RA

DHCPv6-PD and prefix per subscriber

Instead of assigning a single /128 address, the ISP delegates a full prefix to each subscriber — typically /56 (256 /64 subnets) or /60 (16 /64 subnets). The subscriber's router assigns addresses to devices on the internal network automatically.

  • DHCPv6-PD configuration on the B-RAS/BNG
  • Decision on /56 vs /60 based on subscriber profile (residential vs. business)
  • Validation that the subscriber's router is correctly delegating to the LAN
  • Subscriber record update to include the delegated prefix with timestamp

IPv6 on CPE and subscriber-side devices

The biggest practical challenge is the CPE (customer-side router). Equipment sold in Brazil in recent years supports IPv6, but many ISPs ship firmware without it enabled. We identify the problematic models in your base and define the update or replacement path.

  • CPE model inventory and IPv6 support assessment
  • Firmware update or configuration for supported models
  • Troubleshooting of common problems: DAD failure, MTU 1280, ICMPv6 blocked by firewall
  • Subscriber-facing guidance for specific problem reports

IPv6 monitoring and route validation

Deploying IPv6 and leaving it without monitoring is a recipe for silent problems: the prefix stops being announced, a CPE stops receiving a delegation, RPKI expires. We set up the monitoring to catch this before a subscriber notices.

  • BGP session and prefix monitoring for IPv6 (Zabbix + SNMP or API)
  • ROA expiry alerts before they cause route rejection
  • DHCPv6-PD lease pool utilization monitoring
  • Periodic reachability test to IPv6-only destinations

IPv6 with CGNAT in parallel: realistic transition

Most ISPs will run IPv4 CGNAT and IPv6 dual stack simultaneously for several years. The goal is to grow the proportion of traffic going through IPv6 gradually until CGNAT becomes residual. We plan the coexistence so one does not break the other.

  • Happy eyeballs validation (IPv6 preferred, IPv4 fallback without user-visible delay)
  • QoS applied consistently to both IPv4 and IPv6 traffic
  • Periodic metrics: % of sessions using IPv6 vs IPv4
  • Decision criteria for when to remove CGNAT from a subscriber segment

How we work and how to get started

We work on a monthly plan — no one-off projects and no hourly-rate diagnostics. The first conversation is at no cost: we call, you share an AnyDesk session and show us the live network while we share observations. If it makes sense for both sides, we close the monthly plan and go from there.

Talk to us — initial conversation, no commitment. See also: CGNAT for ISPs, BGP for ISPs, IPv6 in the glossary.

FREQUENTLY ASKED QUESTIONS

How does the work start with you?

The first conversation is at no cost. You reach out, we call, you open an AnyDesk session and show us the live network. We share observations on the current IPv6 state, CPE models and the fastest path to dual stack. If it makes sense for both sides, we close the monthly plan and start the following week.

Do you submit to LACNIC on our behalf?

We help prepare the technical documentation for the request. The formal submission to LACNIC must be made by the ISP's technical admin, since it involves account credentials. Once the block is delegated, we handle everything: ROA registration, announcement configuration and monitoring.

Should I delegate /56 or /60 per subscriber?

/56 is preferable: it gives 256 /64 subnets per subscriber, more than enough for any residential or business use. /60 (16 /64 subnets) is acceptable for resource-constrained environments. We make the recommendation based on your total block size and growth projection.

What happens to subscriber records when the delegated prefix changes?

With stable DHCPv6-PD configuration and a persistent DUID, the same prefix is typically re-delegated to the same subscriber on reconnection. When a change does occur, the RADIUS and ERP logs need to record the new prefix with a timestamp — the same compliance logic as IPv4 sessions. We set up this flow from the start.

How long does it take for subscribers to get IPv6?

After closing the plan, the border configuration (B-RAS/BNG + BGP) is typically done within 1 to 5 business days. Subscriber rollout depends on CPE readiness: compatible CPEs start getting IPv6 on the next reconnection. CPEs requiring firmware update or replacement follow a separate schedule agreed with the ISP.