The shift to IPv6 looks straightforward in a lab: enable the address family, advertise a prefix, test connectivity, and move forward. Operating IPv6 across a production broadband network is fundamentally different. It becomes a subscriber-management undertaking, a Customer Premises Equipment (CPE) interoperability challenge, a Layer 2 initiative, a logging system, and an observability transformation—with IPv6 serving as the catalyst that exposes all five simultaneously.

WorldLink Communications began IPv6 testing in May 2016 and went live in July 2019. The network now carries more than one million Internet Protocol over Ethernet (IPoE) subscribers, with 100% IPv6-enabled and approximately 70% of traffic running over IPv6. The operational lessons accumulated during this period combine architectural insights with hard-won experience.

IPoE and dual-stack rationale

Traditional broadband relied on Point-to-Point Protocol over Ethernet (PPPoE). IPoE eliminates the PPP session layer: the CPE performs DHCP, and the Broadband Network Gateway (BNG) identifies the subscriber using information attached to the request—Option 82 circuit-ID, remote-ID, VLAN, MAC, with RADIUS providing policy. This approach simplifies operations and reduces scaling costs. A critical consequence often overlooked is that there is no PPP keepalive. The DHCP and DHCPv6 lease is the session.

The organization evaluated translation and encapsulation approaches before selecting dual-stack, the only option that avoided placing a translator in the path of every customer indefinitely. IPv4 exhaustion was already driving the network toward Carrier-Grade Network Address Translation (CGNAT), a capital expense that grows with each subscriber added—requiring boxes, session management, port blocks, and legal logging obligations. Native IPv6 eliminates this overhead. Every packet shifted to IPv6 is a packet CGNAT never processes.

IPv4 and IPv6 operate as two independent forwarding and service planes sharing a single subscriber session. Treating them as a unified system leads to troubleshooting failures; they must be debugged separately.

Addressing strategy and a critical revision

WorldLink received a /32 allocation from APNIC and structured it conventionally. The allocation strategy assigned /64 prefixes to customers—a decision the author would change if planning today.

A /64 prefix delegation provides exactly one usable LAN, with no capacity for guest networks, separate IoT segments, VLANs behind the CPE, or future expansion. A single /32 holds 16.7 million /56 assignments, so conserving addresses at this level yields no practical benefit. Delegating a /56, or /60 as an absolute minimum, with /48 for business customers, better leverages IPv6's fundamental advantage: address conservation is unnecessary. Using IPv6 with IPv4-style frugality wastes the protocol's primary benefit.

DHCPv6 differs fundamentally from DHCPv4

This is where most dual-stack deployments encounter significant problems. Four key objects appear repeatedly in packet analysis:

  • DHCP Unique Identifier (DUID): Identifies the client, not the MAC or IP address
  • Identity Association for Non-temporary Addresses (IA_NA): The /128 on the CPE's WAN interface
  • Identity Association for Prefix Delegation (IA_PD): The prefix delegated to the customer's LAN
  • Option Request Option (ORO): Option 23 provides the DNS server list; Option 24 provides the domain search list

The exchange sequence is Solicit, Advertise, Request, Reply (SARR). Clients communicate on User Datagram Protocol (UDP) 546, servers on 547, all over multicast. RADIUS behind the BNG supplies Framed-IPv6-Pool, the delegated pool name, and the policing profile.

T1 marks when the client renews with its known server. T2 marks when it abandons that server and rebinds to any listening server. At lease expiry, the client discards everything and begins again from SOLICIT. This final transition is the entire outage.

The renew-rebind cliff

A fiber cut above the Optical Line Terminal (OLT) occurred, but the BNG never detected it, so the subscriber appeared perfectly bound. At T1 the CPE attempted renewal. Silence. At T2 it attempted rebinding. Silence. At lease expiry it dropped the address and prefix, sending a fresh SOLICIT.

This is where CPE vendors diverged. RFC 3315 specifies that the client sends one SOLICIT with one transaction ID containing both IAs. The BNG sees one client renegotiating and recovers cleanly. RFC 8415 permits a client to maintain separate state machines per IA option, so it sends one SOLICIT with Transaction Identifier (XID) 1 for IA_NA and another with XID 2 for IA_PD. Now the BNG sees two clients. Neither completes because neither request represents a whole session. Retransmit timers activate, and old state never clears.

WorldLink measured 116 SOLICITs in one minute from a single CPE. Across just 10% of an 80,000-subscriber BNG, this projects to roughly 15,467 SOLICITs per second. At that rate, the DHCPv6 control-plane violation counter never clears.

The DBOR effect

Delete-binding-on-renegotiation (DBOR) instructs the BNG that a SOLICIT arriving while a client is already bound should tear down the existing binding and rebuild it. This exists for valid reasons in DHCPv4. In DHCPv6, with a CPE emitting new SOLICIT XIDs unpredictably, it creates cascading failures.

The customer's session gets destroyed and rebuilt for both IPv4 and IPv6, without the CPE receiving notification. The CPE continues using the address and prefix it already held. At the next renew, the BNG responds with status code 13: NoAddrAvail (2) and NoPrefixAvail (6). The CPE retries. The cycle continues until a power cut or fiber cut interrupts it.

From the operations floor, the impact was:

  • No IPv6 for every subscriber caught in the failure
  • CGNAT cards spiking as traffic fell back onto IPv4 NAT
  • Call center flooded with reports that Facebook and YouTube are slow (customers never call about DHCPv6 problems)

The immediate workaround that worked was deploying an older router, because older firmware still followed RFC 3315.

Vendor discussions circled for a period. The CPE vendor was correct that SOLICIT-with-ORO-only is legitimate under RFC 8415, and that ORO-23 and ORO-24 are required for Broadband Forum (BBF) IPv6 compliance. The BNG vendor was correct that it was already returning both options in its REPLY. Both statements were true. The customer still had no IPv6.

The fix was never a configuration knob. It was agreement. RFC 8415 section 18.1 and RFC 7550 section 4 both specify that a client should use a single transaction for all IA options on an interface, so the client maintains one session and one state machine. Recommendations became:

  • Suppress ORO-only SOLICIT and REQUEST messages
  • Use one state machine for IA_NA, IA_PD, and ORO
  • Use a single exchange for multiple IA options in SOLICIT, RENEW, and REBIND
  • After a rebind failure, terminate older SOLICIT processes before starting new ones
  • Retransmit the same XID until SARR completes
  • Return NoBinding rather than NoAddrAvail / NoPrefixAvail when a client-side stack reset is needed
  • Enable Option 24 ORO parameters if the platform supports them
  • Keep identical lease timers for IA_NA and IA_PD
  • Think very hard before enabling DBOR for DHCPv6 at all

The overarching lesson, which cost more than any specific detail, is that in dual-stack IPoE there is no keepalive. Persistent DHCP state for the full lease duration is the only mechanism holding the subscriber session together. Anything that deletes bindings out from under a client is manipulating the session itself.

Early failures were primarily Layer 2

Before addressing the issues above, a simpler problem emerged: DHCPv6 runs on multicast, and the access network had been carefully tuned over years to suppress multicast. Every multicast-related issue cost real customer-visible downtime. The snooping issue is the most seductive, because DHCP snooping genuinely helps troubleshooting, until 8,000 subscribers run on an OLT with a four-entry-per-CPE snoop table. Mass power restoration churns the table, and the OLT starts discarding DHCPv6-REPLY or DHCPv4-ACK on the return path. CPEs become idle, and the snooping database becomes beautiful and useless.

Leaving the OLT performing pure forwarding and ranging, with snooping deployed somewhere that can afford the resource cost, proved more effective.

The operational surface beyond major incidents

Several issues do not warrant individual war stories but will surface in operations:

Dual-stack shaping: One RADIUS bandwidth value becomes one dynamic policer and two filter sets—IPv4 in/out, IPv6 in/out. Misconfiguration results in customers receiving double their plan or half of it.

Security, because NAT was never a firewall: Bogon filtering on upstream routing policy. Control-plane filters admitting infrastructure prefixes only. Reverse Path Forwarding (RPF) on the gateway. Exploitable ports blocked. RA Guard and DHCPv6 Guard in the access layer. And the uncomfortable reality: giving a customer a globally routable prefix means their CPE firewall is now load-bearing, and CPE IPv6 firewalling remains noticeably weaker than the IPv4 equivalent in many cases.

CPE diagnostic gaps: On IPv4, you can see which device received which lease. On IPv6, most consumer CPEs do not report which end device holds which address, and many still lack IPv6 ping or traceroute in the web UI. Support teams debug blind without planning for this gap.

MTU, end to end: 'Google works but this one site doesn't.' is a Maximum Transmission Unit (MTU) or Path MTU Discovery (PMTUD) problem far more often than anything else. Validation must follow the real path: Ethernet, VLANs, Multiprotocol Label Switching (MPLS), BNG, CGNAT, not the number on the CPE's status page.

CGNAT logging and correlation: If 10.10.10.25:52341 became 203.x.x.x:49122 at 12:31:45, you must be able to name the subscriber months later. This is not optional; it is a legal requirement in most jurisdictions.

Design for the reconnection storm, not the average: The question is never 'what happens when everything works?' It is 'what happens when 100,000 subscribers reconnect in the same thirty seconds after a regional power cut?' DHCP infrastructure requires horizontal scale, redundancy, lease-database resilience, and failure-domain isolation sized for that moment.

Build the data model, not the dashboard

At one million sessions, the question is never 'which IP address is this?' It is 'which subscriber owned this address at this exact moment, and what else was true about them?'

WorldLink runs the standard stack: LibreNMS, Grafana, InfluxDB, Telegraf, NetBox, ELK, and flow monitoring. The tooling choice is not the point. Correlation is the point—one subscriber key that every other system can join on.

If answering 'show me everything for this subscriber' requires five systems and a spreadsheet, the network is not the problem. The data model is.

Two principles matter more than tooling selection:

  1. Monitor IPv4 and IPv6 as separate KPIs—not as 'Internet is up'. Track DHCP success rate and DHCPv6 success rate separately. Measure prefix-delegation failures as their own metric. Monitor CGNAT session and port use on one side, and IPv6 prefix use and reachability on the other. The DBOR incident was visible in the DHCPv6 violation counter long before it appeared in a customer complaint. The organization simply was not treating it as a first-class signal.
  2. Size BNGs by the resource that runs out first, not by the subscriber count on the datasheet. Track IPv4 and IPv6 sessions, DHCP and DHCPv6 transaction rates, Neighbor Discovery (ND) and Address Resolution Protocol (ARP) state, Forwarding Information Base (FIB) and Routing Information Base (RIB) entries, packets per second, and control-plane use. A BNG can sit at half its rated subscriber capacity and still fail because neighbor-discovery state hit a wall.

The number that actually matters

When WorldLink went live in 2019, it had approximately 100,000 IPv6-enabled customers out of 290,000, and IPv6 had just crossed half the traffic. Today it is 100% enabled and roughly 70% of traffic on a network more than three times the size.

These two percentages are not equivalent metrics, and the gap between them is the entire story. A subscriber with an IPv6 address and broken prefix delegation counts as enabled. So does one behind a CPE that never successfully renews. Enablement reflects what the provisioning system believes. Traffic reflects what actually happened. Bytes cannot be faked, and every point moved from IPv4 to IPv6 is CGNAT capacity never purchased.

Do not report IPv6 adoption as the percentage of subscribers holding an address. Report the percentage of traffic successfully using it. The first number produces a nicer slide. The second tells you whether it works.

What would be done differently

  • Observability and automation from day one, not as a phase two that never arrives. Everything in the operational surface section was retrofitted, and retrofitting correlation across a live million-subscriber network is considerably harder than designing for it.
  • A CPE interoperability lab before mass deployment. Not a reference CPE, but the actual devices customers actually have, at the firmware versions they actually run. Every failure in the DHCPv6 and DBOR sections was a CPE-behavior failure that a lab with the right two routers would have caught in an afternoon.
  • Compliance agreed in writing between CPE and BNG vendors, naming the RFC, before either box is deployed at scale. 'Both ends are compliant' is not the same as 'both ends are compatible', and you discover which one you have at 8pm on a Friday.
  • A /56 prefix. The organization chose /64 due to CPE limitations.

The takeaway

After seven years of operating IPv6 at scale, the most valuable insight to pass forward is this:

  • IPv6 deployment is not primarily an IPv6 project. The protocol is well understood and thoroughly documented. The hard part is everything it touches: subscriber management, DHCP, DHCPv6, RADIUS, the BNG, CGNAT, CPE firmware, Layer 2 access, security, logging, monitoring, and the support process that explains all of it to a customer who just wants YouTube to load.
  • IPv6 works at massive broadband scale. WorldLink has one million subscribers as proof. But it works because of the system built around it, not because somebody enabled an address family.
  • Do not measure it by how many subscribers have an IPv6 address. Measure it by how much real traffic is successfully using one.

That is when IPv6 stops being a project and becomes part of the network.

Kijush Maharjan is the Principal Network Engineer at WorldLink Communications and the founder and Secretary of npNOG. He is recognized as an IPv6 pioneer in Nepal.