Summary

  • Digitel’s operations manager says its call-detail records captured IPv4 but not IPv6, and that closing the gap took close to another year. The account is not backed by a public schema, sample or audit.
  • Venezuela’s Provision 096 sets IPv6 implementation and transition-reporting requirements. The materials reviewed do not show that it requires a particular CDR field, retention period or subscriber-lookup procedure.
  • Network capability and time-specific address records are different readiness claims. One cannot verify the other.

A protocol can arrive before its record

The least visible part of a mobile IPv6 transition may sit outside the packet path. In a 14 October account published by LACNIC, Andres Carmona, Corporación Digitel’s Centralized Operations Manager, says the operator’s call-detail records stored IPv4 addresses but not IPv6. He says resolving the gap took close to another year.

That sentence changes the shape of the rollout story. A dual-stack interface can be active while an adjacent operating system still treats the old address family as the only one worth recording. Digitel’s public account does not provide the underlying record format, but it identifies a boundary between two capabilities: carrying IPv6 traffic and preserving the information an operator says it needs to associate a subscriber with an address at a particular time.

The account is unusually useful because it names a control surface, not because it proves a failure. Carmona describes the CDR issue as the final regulatory bottleneck. Yet he does not publish a sample record, an audit result, a regulator’s finding or the number of subscribers whose activity would have been affected. Nor does the post say that IPv6 service waited until the records were changed. It says the record gap took nearly another year to resolve. Those are narrower facts than a claim that service was untraceable or that customers were harmed.

The rule and the record answer different questions

Venezuela’s CONATEL published Administrative Provision 096 in Official Gazette No. 43.150 on 16 June 2025. The provision’s stated object is to set measures for IPv6 implementation and targets for telecom operators using IP. A legal summary by LEĜA Abogados describes a two-year maximum for implementing native-IPv6-capable network architecture, hardware and software, alongside a 30-day notice and transition-plan process.

Those obligations define a deployment path. They do not, on the evidence reviewed here, specify how a call-detail record should represent an IPv6 address. Carmona’s description may reflect an operator’s interpretation of the records needed to meet a broader traceability expectation, a separate compliance concern, or a design requirement particular to Digitel. The published account does not identify which. The distinction matters: an operator’s characterization of a bottleneck is evidence of its own implementation experience, not proof that a regulator mandated a database field.

The timeline also resists a neat compliance verdict. Provision 096 took effect on publication, and the two-year period summarized by LEĜA runs into June 2027. At the 16 October 2026 research cutoff, that outer date was still ahead. Carmona says Digitel was the first mobile operator to meet the dual-stack objective, but no regulator checklist or independent test is supplied here to confirm what was tested, when, or across which services. The account should be read as an operator’s reported result, not a national audit.

This is not a semantic distinction. A policy can ask whether equipment and software support native IPv6; a service test can ask whether sessions complete; a record test can ask whether a later reviewer can reconstruct which address was assigned, for what interval and under which account. Each test observes a different layer. Passing one does not imply passing the others.

A logging standard is not a description of Digitel

RFC 6888 helps explain why address records can become operationally important, but only within its scope. Section 4 discusses carrier-grade NAT mapping logs. Where multiple subscribers share an external IPv4 address, an operator may need the external address, port, timestamp, protocol and a subscriber identifier to map an observed connection back to a subscriber. The RFC labels its illustrative field list informational rather than a requirement. It also warns that mapping logs can grow substantially and says a CGN should not record destination addresses or ports unless administratively necessary, citing privacy concerns.

That is a conditional comparison, not a claim about Digitel. Carmona’s post does not say that the operator uses CGN, and a CDR is not automatically the same thing as a per-mapping NAT log. The RFC cannot fill the gaps in the operator’s account. Its value here is to show that logging design has a two-sided control problem: enough information to answer a defined operational question, with limits on volume and unnecessary observation.

The same discipline applies to the address family. A record that once stored IPv4 may need a defined IPv6 representation, but the public account leaves open whether the change involved a field, an identifier, a billing interface, a reporting pipeline or several systems. It does not describe precision, retention, access, corrections or tests. A reader cannot infer completeness from the phrase “we solved it.”

Ask for the test, not another headline number

The next useful evidence would be a privacy-safe verification note. It could state the scope and date of the test, whether the address is IPv4 or IPv6, the assignment interval and account linkage, how timestamps are normalized, how long records are retained, who can correct or access them, and what share of the tested records passed. It need not publish subscriber identities or raw CDRs. A regulator’s checklist or an independent assurance statement could establish whether these controls were tested against Provision 096, a separate rule or Digitel’s own operating standard.

That test would not settle every question about IPv6 quality. It would answer a narrower one: whether a network’s reported dual-stack capability is accompanied by a record process the operator can explain and verify. Without it, the public record supports two claims of different strength—CONATEL set an IPv6 implementation framework, and Digitel says its CDR system took nearly another year to accommodate IPv6. It does not connect them into a legal finding.

The implementation lesson is therefore modest but durable. A cutover plan should name the service, billing and record systems that must change alongside the forwarding path, and define evidence for each. If a requirement concerns network capability, show a network test. If it concerns subscriber-address traceability, show a protected record test. Treating one as a proxy for the other leaves the hardest interface out of view.

Sources