Summary

  • Corporación Digitel’s operations manager says IPv6 reaches more than five million connected mobile devices, 74% of the connected-device total, and carries 42% of mobile traffic. The post gives no measurement period or method.
  • He says DNS-server load rose from 20% to about 45%. Without a definition, time series or capacity threshold, that is an operating signal—not evidence of saturation or customer harm.

Three measures, three denominators

A LACNIC guest post published on 14 October describes Digitel’s mobile IPv6 transition. Andrés Carmona, identified in the visible byline as Corporación Digitel’s Centralized Operations Manager, attributes the headline figures to the operator. The post does not say when the device count was taken, how “connected” was defined, or how traffic was sampled. LACNIC also says guest authors’ views need not represent the organization.

The percentages answer different questions. The device share is not the traffic share. They cannot be combined into one adoption score, treated as a conversion rate or read as a trend: the post publishes no earlier series.

The third figure concerns infrastructure. Carmona says DNS-server load moved from 20% to nearly 45% as dual stack spread. That may matter to capacity planning, but the post does not define “load.” It gives no query rate, CPU or memory measure, peak-versus-average distinction, interval, server cohort, latency, error rate or usable capacity. A value near half does not establish that half the capacity remains.

The migration included a record-keeping step

Carmona dates the internal push to around 2015 and the formal mobile project to 2016. He describes a small test, employees for about three months, new lines and wider rollout. According to his account, 4G used one subscriber template while 3G moved in batches of 250,000–500,000. He says nearly five million users appeared on IPv6 about two days after the 4G dual-stack profile was enabled; this is the operator’s account, not an audited count.

The less visible work touched control systems. The post mentions session-control compatibility, DNS adjustments and billing changes. Carmona says call-detail records stored IPv4 but not IPv6, leaving a traceability gap that took close to another year to resolve. The post offers no audit, sample or affected-subscriber count; it therefore establishes neither a breach nor a specific user impact. It does show that enabling a protocol and retaining records that can reconstruct address assignment are separate tasks.

A 2022 core modernization also renewed the DNS platform, according to Carmona. He says LACNIC training and regional operator discussions helped sustain internal support when IPv4 scarcity did not yet create immediate urgency. This is an implementation account, not an independent assessment.

What the standard explains—and what it cannot

RFC 8305 describes asynchronous A and AAAA queries that a dual-stack client can make while preparing a connection. It explains the mechanism; it does not show how many requests reached Digitel’s resolvers, what caching absorbed or what the reported load percentage measures. The standard does not validate the reported change from 20% to 45%.

The supported conclusion is bounded: Digitel reports a large mobile IPv6 footprint and a DNS metric its team considers relevant to future capacity. Readers cannot tell whether the figure is an average, a peak or a measure of a particular resource. The adoption percentages do not substitute for a public time series.

Sources: LACNIC guest post by Andrés Carmona; RFC 8305.