Summary

  • A dedicated-link sale establishes a connectivity service; it does not, by itself, establish that an IPv4 block was assigned to the customer.
  • LACNIC’s September 2026 public discussion records a portal observation and a Brazilian ISP’s example, but does not say whether any addresses changed hands or how the case should be classified.

On 14 September, a participant on LACNIC’s policy list asked why a sub-assignment option appeared in MiLACNIC but not in Registro.br, and whether a deadline applied. The next day, a Registro.br participant described work between LACNIC and the national internet registries to operationalise the new rule, while noting that each system has its own issues. A further reply said the option was visible in MiLACNIC for an ASN the writer knew, though it had not yet been needed. The writer added that a Brazilian ISP’s sale of a dedicated link to a non-Brazilian company had prompted the question. (14 September question; 15 September NIR reply; dedicated-link clarification)

That account is useful because it names a real operating situation. It is also incomplete in exactly the place where a policy conclusion would begin. The message does not say that the ISP supplied a prefix to the customer, that the customer originated routes, that the customer had an autonomous system number, or that any address changed hands. It does not say where the customer’s network was located. A dedicated link is evidence of a service relationship. It is not, without more, evidence of a resource recipient.

The distinction matters because LACNIC’s policy LAC-2025-5, “Sub-Assignment of IPv4 Resources to Third Parties,” is about a relationship to IPv4 number resources. The current policy page records ratification on 24 March 2026. Its operative text applies to IPv4 and sets conditions for a qualifying sub-assignment. Among them are recipient-side requirements, limits on the block size, use or immediate need thresholds, a link in WHOIS between the block and the recipient’s ASN, and a public movement-log event. It also keeps ultimate responsibility with the LACNIC member making the sub-assignment and imposes a waiting period after a transfer or recovery before sub-assignment. (current ratified text)

Those controls do not turn every customer connection into a resource transfer. They make the underlying classification more important. If a provider sells transport while retaining and operating its own address space, the customer’s purchase of a dedicated circuit does not by itself answer whether any block was sub-assigned. If the provider separately places a block under the customer’s operational use, the service label cannot make that resource relationship disappear. The public example supplies too little detail to choose between those possibilities.

The resource test sits behind the service label

LACNIC’s own resource-request guidance helps keep the categories apart. It treats providers offering services such as web hosting, colocation, virtual private servers or dedicated links in the context of an internet service provider. The same guidance distinguishes an organisation operating its own infrastructure without reassigning address blocks to third parties. Requests from Brazil and Mexico are routed through their corresponding national internet registries. (LACNIC resource-request guide)

That guidance does not classify the September example. It does show why the noun “link” is a poor proxy for the policy question. A circuit describes what the customer buys: connectivity between network points. A resource record describes a different object: which organisation is the recipient of an IPv4 block, and what evidence links that organisation to the resource. One contract or invoice may cover both; one may also exist without the other.

This is a familiar boundary in infrastructure economics. Firms bundle capacity, equipment, operations and addressing into one commercial offer because customers often want an outcome, not a list of separately managed inputs. The bundle lowers coordination costs. It can also obscure which party controls a scarce input and bears the corresponding registry obligations. The right response is not to assume that every bundled service contains a sub-assignment. It is to identify the resource and the recipient before applying a rule designed for that relationship.

LAC-2025-5 gives that inquiry concrete dimensions. A qualifying block must fall within the policy’s current size range. The recipient must satisfy the stated ASN and IPv6 conditions. The utilisation test distinguishes existing use or immediate need from a plan to reach the higher threshold within a year. The WHOIS relationship must identify the recipient ASN, while the public movement log records the block, ASN, date and start or end event. The source page also places continuing responsibility on the member that sub-assigns.

These are not generic indicators of a customer relationship; they are fields in a specific resource-governance arrangement.

The distinction between a customer’s nationality and its network is equally important. “Non-Brazilian company” tells the reader something about the company as described by the participant, but not where its routers, users or address space are located. It does not reveal whether the customer has an ASN or whether the provider’s own address block is being used. Geography may shape which NIR portal is involved; it cannot stand in for the recipient and resource facts required by the policy.

A portal difference is a question, not a finding

The September thread should be read as implementation evidence with a narrow scope. LACNIC’s policy assistant had said on 1 September that implementation was expected before the end of the year, beginning with basic aspects while technical challenges remained. The subsequent participant described seeing an option in one system but not another. A reply referred to joint operational work and system-specific issues. Another participant said the option was visible for a known ASN but had not been used. (1 September implementation note)

Taken together, the messages show that users were trying to understand how the policy would appear in separate interfaces while implementation was still underway. They do not establish that one portal was defective, that the option was universally available in MiLACNIC, that it was required to appear in Registro.br at that moment, or that a deadline had been missed. The messages are dated observations and explanations, not a controlled comparison of system behaviour.

The implementation problem is nevertheless real in a practical sense: a policy that depends on a particular recipient, block, ASN and dated event must be made usable by members and, where relevant, NIRs. A menu that cannot be found by a particular account may delay a filing or create uncertainty. But the cost should be measured from verified cases, not inferred from one exchange. Account eligibility, the resource relationship, portal rollout and user familiarity are competing explanations until an operator confirms which applies.

The economical sequence is therefore simple. First identify the address block at issue. Then identify the party that receives or controls it, the recipient ASN and the relevant registry record. Next determine whether the policy’s conditions apply and whether the public event record is required. Only after that should an operator ask whether a portal has the correct workflow for recording the event. Reversing the sequence—starting from a missing menu and inferring a sub-assignment—risks treating interface uncertainty as a legal or technical conclusion.

The same discipline protects both sides of the relationship. A provider should not have to register a resource event merely because a customer buys a dedicated circuit if no qualifying resource relationship exists. A customer and registry should not be left without a resource record merely because the commercial contract calls the arrangement a link or managed service. The test is the underlying allocation and control of the address block, documented through the evidence the policy specifies.

What a useful implementation record would show

For the member, a reliable workflow should make the relevant resource relationship legible before submission: the block, the intended recipient, the recipient ASN, the use or immediate-need basis, and the start or end date of the arrangement. If the policy applies, the registry record and movement-log entry should agree on those fields. If it does not apply because the provider retains the addresses and has not reassigned a block, the explanation should be equally clear to the customer and to the staff member handling the request.

For LACNIC and the NIRs, the implementation question is not only whether a button appears. It is whether the member can determine which system is authoritative for its account, whether the same relevant fields can be completed in the applicable workflow, and whether a submitted event can be checked against the resource record. The September exchange does not answer those questions. A subsequent implementation update could do so by describing the rollout stages, the portal responsibilities and the route for members whose account or resource is handled by an NIR.

That is not a demand to publish confidential customer or contract details. The policy itself calls for a public movement-log event with a defined resource record. A useful operational receipt can expose the event fields and system status without turning the customer’s commercial terms into public data. Where no qualifying sub-assignment exists, a private support response may be enough; the public policy record should not imply an event that did not occur.

The lesson is modest but consequential. A dedicated link can carry an address, and a commercial bundle can include multiple network inputs. Yet the policy question is not answered by the service’s marketing name, the customer’s nationality or the presence of a portal option. It is answered by who receives the IPv4 resource, how that relationship is recorded and whether the current rule’s conditions are met. On the evidence available, the September example raises that question; it does not resolve it.

Official language versions of LAC-2025-5