Summary
- Cloud-provider address power is created when public IP identity becomes account-bound, platform-managed and procurement-mediated rather than merely held in a registry.
- RIPE NCC's service region, large LIR base, exhausted IPv4 free pool and registry services make its records important evidence for portability, but not a mandate for cloud-market intervention.
- BYOIP and advertised-prefix products can preserve customer-owned public identity, yet admission checks, route-origin rules, authorisation evidence and platform approval make portability conditional.
- Reverse DNS, RPKI/ROAs, route acceptance, reputation history, allowlists and security-service coupling are now commercial control surfaces in cloud migration and cloud exit.
- Public-sector and regulated-customer procurement can unintentionally harden dependence on provider-owned pools when tenders value operational convenience but under-specify exit evidence.
- RIPE NCC should remain a thin, accurate ledger, but improve the portability value of registry evidence so scarcity cannot be too easily converted into customer dependence.
The exit meeting where address power becomes visible
The most revealing cloud meeting is often not the one in which a company first decides to move its workloads. It is the one in which it tries to leave. The diagrams on the wall may show compute clusters, managed databases, load balancers, firewalls and observability tools. The budget conversation may begin with subscription fees, reserved capacity, egress charges and staff retraining. But before long the discussion often turns to the less glamorous details of public address identity: which IPv4 ranges are in use, who controls them, how many outside systems recognise them, which customers have allowlisted them, which mail and fraud systems remember their behaviour, whether reverse DNS will change, whether a route origin authorisation exists, and whether the next provider will accept the prefix at all.
That is where cloud-provider address power appears. It does not require a provider to own every scarce address. Nor does it depend only on the size of a platform's public IPv4 inventory. Power is created when public network identity is wrapped into the customer's cloud account and then made operationally convenient inside that account. A provider-owned address is issued by API, attached to a service, protected by a security product, described in a compliance architecture, written into enterprise allowlists and observed by third-party risk systems. It becomes part of the customer's external face. The customer may not think of it as an asset. It may think of it as configuration. That is exactly the point.
The economics are simple but easy to miss. Scarce IPv4 resources have become expensive and administratively dense. Enterprises and public bodies want cloud services because platforms simplify operations. A provider that supplies public addresses as part of the managed service can turn that convenience into a bargaining position. The customer receives speed, automation and support. It also accepts that part of its public identity is mediated by the platform. If later it wants to move, the cost is not limited to rehosting workloads. It must persuade customers, regulators, partners, anti-fraud systems, mail filters and security teams to trust a different public face. The address is only a number, but the evidence around the number is what makes it costly.
RIPE NCC sits near the root of that evidence in its region. Its service region spans Europe, the Middle East and parts of Central Asia and covers more than 75 countries. Its membership includes more than 20,000 Local Internet Registry organisations. Its IPv4 free pool ran out in November 2019. Its services include registry records, the RIPE Database, RPKI, reverse DNS, and routing and measurement information. These facts do not make RIPE NCC a cloud regulator. They make it a ledger whose records are repeatedly used by other parties to decide whether a public address claim is credible. In a market where cloud providers mediate more of the public address experience, the quality and portability of that evidence matters.
The question for a regional internet registry is therefore narrow but important. It should not attempt to fight cloud market power directly. It should not become a landlord of scarcity or a discretionary licensing bureau for cloud architecture. Its duty is thinner and more durable: protect uniqueness, accuracy and continuity, and make records useful enough that address holders can prove what they control. A common ledger lowers switching costs when its evidence travels cleanly across platforms. A weak or ambiguous ledger lets powerful intermediaries translate address scarcity into dependence.
Two kinds of public address identity
Cloud customers now operate with two overlapping forms of public address identity. The first is provider-owned identity. A customer launches a service and receives addresses from the provider's pool. Those addresses may be static within an account, reserved through a regional product, tied to a load balancer or bound to a managed endpoint. The public internet sees the address, but the commercial and operational control is inside the provider's platform. The customer has contractual access, not independent control. The platform can automate attachment, detachment, firewall rules, DDoS protection, reverse DNS handling in some cases, monitoring and lifecycle events. The address feels native because it is native to the provider's machinery.
The second form is customer-owned portable identity. The customer brings a prefix it already controls, asks a cloud provider to advertise it, and uses that public range for workloads in the platform. Major cloud providers have developed forms of this model, often described as bring-your-own-IP, custom IP prefix or advertised public prefix services. The product language varies, and the details change over time, but the broad pattern is common: the customer must prove control or authorisation, meet size and registry conditions, align route-origin evidence, pass platform checks and accept the provider's operational constraints. The platform is not merely routing a number. It is deciding whether the customer's registry evidence is good enough to admit that number into the cloud fabric.
Provider-owned identity is efficient at the start. The customer avoids transfer markets, registry paperwork and coordination with network teams. It can build from templates. It can destroy and recreate systems. It can use cloud-native security controls. It can let procurement buy "public connectivity" as part of a service rather than acquire and operate internet resources. For start-ups, small software firms and public-sector digital teams, this is often rational. The alternative can be slow, expensive and unfamiliar. Scarce IPv4 has made independent address holdings harder to justify when a provider can supply an address by API.
Customer-owned portable identity is costly at the start but valuable at the end. It allows an enterprise to preserve the public face of a service when shifting hosting arrangements. It can keep partner allowlists stable. It can preserve mail and abuse reputation where relevant. It can allow a regulated firm to show continuity of external endpoints during resilience exercises. It can also support multi-cloud or hybrid designs in which the same public identity is not solely anchored to one provider's pool. The customer gives up some simplicity but keeps a piece of bargaining power.
The distinction is not moral. Provider-owned pools are not inherently abusive. BYOIP is not inherently liberating. A customer can misuse a portable prefix, fail to maintain registry data, create routing risk or treat portability as a badge while remaining operationally dependent in other ways. A provider can supply addresses honestly and make migration easier than many private networks ever did. But the institutional question remains: which party can prove control, which party can change the route, which party can update the reverse delegation, which party can survive a dispute, and which party bears the commercial cost of re-establishing trust when the account relationship ends?
In that sense, address power is a set of frictions. It lives in the gap between legal control, registry evidence, platform policy and operational recognition by outsiders. A provider with a large address pool and mature automation can make the easiest path the least portable one. A customer with a clean, well-documented prefix can still face admission checks, time delays and route-acceptance limits. The registry does not choose the commercial winner. Yet registry records shape the evidence that both sides use when they bargain.
Scarcity makes the ledger valuable, not sovereign
IPv4 exhaustion is sometimes described as if it automatically transfers authority to whoever sits near the registry. That is the wrong conclusion. Scarcity makes accurate records more valuable. It does not turn a clerk into a landlord. RIPE NCC's free IPv4 pool running out in November 2019 is a market fact and an administrative milestone, not a reason for the registry to allocate cloud leverage according to industrial policy. The useful role is not to ration cloud competition. It is to make sure that the records showing who holds, maintains, delegates and authorises number resources remain coherent enough to reduce uncertainty.
The RIPE NCC region is unusually exposed to this issue because it is both broad and commercially varied. It includes dense Western European cloud markets, regulated financial centres, emerging digital economies, public-sector cloud programmes, internet exchange ecosystems, hosting firms, telecom operators, research networks and firms that acquired addresses long before cloud migration became normal. The service region stretches across Europe, the Middle East and parts of Central Asia. More than 20,000 LIR organisations interact with the registry system. A single commercial pattern will not describe all of them. Some have professional network teams and mature registry hygiene. Others treat addresses as an inherited administrative detail.
Cloud providers operate across this diversity with standardised products. Standardisation is their strength. It lets a platform admit a prefix, verify a cryptographic or registry signal, apply route policy, expose an API and run the same process in many jurisdictions. That is efficient, but it also means platform policy can become a private translation layer between the registry and the customer. If the registry record is ambiguous, stale or hard to interpret, the provider may ask for more evidence, delay approval or decline the range. If the customer lacks internal knowledge, the provider's answer becomes the practical law of portability.
This is why the ledger matters even when it is thin. A thin ledger is not passive. It is an institutional device for reducing argument. It records uniqueness, stewardship and authorisation in a way that many downstream systems can rely on without asking the registry to approve every commercial use. When evidence is clear, the holder can approach multiple providers, security vendors and network operators with the same basic proof. When evidence is weak, each platform can create its own admission ritual, and the strongest platforms can make that ritual part of the customer's dependence.
The danger is not that RIPE NCC becomes irrelevant. It is that its evidence remains central but is consumed through private interfaces that customers cannot easily challenge. A provider may say that a prefix does not meet the product's requirements. Another may demand a different authorisation format. A procurement team may not understand the difference between a provider-owned address and a portable prefix. A security team may accept platform defaults because they reduce immediate risk. The registry record is still there, but it is not doing enough work for the party that needs portability most.
The constructive answer is not a heavier registry. It is better portability evidence. The registry should not decide which cloud provider must accept which customer. It should help make resource-holder claims, reverse delegation status, route-origin intent and continuity signals legible. If a customer has maintained accurate records and can show a clean chain of authority, that evidence should be easy to use across platforms. Scarcity then becomes a reason to improve proof, not a pretext for either registry overreach or platform discretion.
BYOIP as an admission market
Bring-your-own-IP sounds like a portability product. It is also an admission market. A customer arrives with a prefix and asks a cloud provider to carry it. The provider must protect its routing system, its other customers, its reputation with upstream networks and its security posture. It cannot simply accept any asserted range. It therefore asks the customer to prove control, satisfy registry and route-origin conditions, create authorisation signals, and wait for review. That is sensible. It is also where a public address becomes subject to platform judgement.
AWS, Microsoft Azure, Google Cloud and other major platforms publish product materials for customer-supplied public prefixes. Those materials are useful factual exhibits, not a complete theory of the market. The documents tend to show a common pattern: the platform requires evidence that the customer controls the range or is authorised to use it; the prefix must meet technical size and registration expectations; route-origin information or authorisation must be compatible with the provider's advertisement; the provider reserves discretion to approve, reject or constrain use; and the customer must integrate the admitted prefix into the platform's own lifecycle. Details differ and product rules evolve, but the admission structure is stable enough to matter.
The admission market creates asymmetry. A large enterprise with a network team, in-house counsel, established registry contacts and multiple providers can prepare the evidence. It can create or adjust ROAs, update contact data, coordinate reverse DNS and press account teams. A smaller firm may know only that it has a prefix in old paperwork or that a hosting partner once arranged connectivity. A public body may depend on a systems integrator that treats public addressing as implementation detail. The cloud provider then becomes the expert interpreter of the customer's own identity. That is useful support, but it is also leverage.
The leverage is heightened by time. A failed BYOIP admission is rarely an abstract policy dispute. It can delay a migration window, a disaster-recovery test, a tender commitment or a product launch. If the provider-owned alternative is available immediately, project pressure favours the platform pool. The customer may intend to return later and fix portability. Later often means never. Once the service has launched on provider-owned addresses, third parties start to remember those addresses. The cheap decision becomes embedded in allowlists, security logs, customer integrations and audit evidence.
BYOIP is therefore not merely a feature to count. The deeper question is whether it works as practical exit infrastructure. A provider can advertise a portability option while maintaining narrow eligibility, slow reviews, complex evidence requirements or operational constraints that make many customers choose native pools. That may reflect legitimate risk control. It may also preserve the provider's commercial position. Outsiders cannot evaluate the balance unless portability evidence is clearer and more standardised.
RIPE NCC's role is indirect. It should not tell a platform how to engineer its network. It should not force a provider to carry a route that creates security or operational risk. But it can make the customer's side of the admission process less opaque. Registry records, maintained contacts, route-origin data, reverse delegation and related evidence should be coherent enough that a holder can approach a provider without reconstructing its own history from archives. The fewer mysteries in the public ledger, the less room there is for cloud admission to become a private veto over portability.
Account boundaries and API automation
Cloud platforms make public addressing feel modern by turning it into an account resource. That is convenient because enterprise users want programmable infrastructure. A public address can be reserved, tagged, attached to a load balancer, moved between instances, monitored, protected, logged and billed. It can appear in infrastructure-as-code templates. It can be subject to identity and access rules. It can be created by a platform team rather than a network engineer. This is the operational genius of cloud. It is also the mechanism by which public address identity becomes account-bound.
Account boundaries matter because they define who can act. If an address comes from a provider pool, the customer usually cannot take it outside the provider. It may be able to reserve it within a region, keep it across service restarts, or move it among products inside the same platform. But the account is the fence. The customer can automate inside that fence and becomes dependent on the fence for identity continuity. A corporate reorganisation, account dispute, unpaid invoice, compliance lock or failed migration can then affect not only compute access but the public face of the service.
BYOIP changes the boundary but does not remove it. Once a customer-owned prefix is admitted into a cloud platform, it is still usually operated through the platform's APIs and account model. The customer may retain registry control, but its day-to-day use is mediated by the provider's routing and service layer. De-provisioning the prefix, moving it to another account, adjusting advertisement, changing regional use or combining it with security services may require platform-specific steps. In this sense, portability is not a binary property. It is a chain of operational acts that must be possible under pressure.
The convenience of automation can hide the loss of independent practice. Network teams that once handled BGP sessions, reverse delegations and provider coordination may be replaced by platform teams whose expertise is cloud policy. That can be efficient and even safer for many workloads. Yet it means fewer people inside the customer can distinguish between an address the firm can carry elsewhere and an address the platform merely leases as part of service delivery. Procurement may see both as "static IP". Developers may see both as endpoint configuration. Auditors may ask whether the service is resilient without asking whether public identity is portable.
This semantic blur is commercially useful to the provider. The more the customer experiences public addressing as a platform feature, the less likely it is to price the exit cost at the start. By the time exit is contemplated, the address is entangled with account IAM roles, logging, DDoS policies, firewall groups, load-balancer certificates, DNS automation, third-party monitoring and customer documentation. The path out is not impossible. It is tedious, risky and politically unattractive. Tedium is a form of lock-in.
A thin registry can counter this only by making the difference legible. Registry evidence should help customers, auditors and procurement teams ask better questions. Is this public identity provider-owned or customer-controlled? If it is customer-controlled, where is control recorded? Are route-origin authorisations aligned with the intended cloud origin? Who controls reverse DNS? What must be changed if the account relationship ends? These are not questions for a cloud competition case. They are continuity questions. The registry's records should make them answerable before a crisis, not after.
Reverse DNS, RPKI and route acceptance as portability evidence
Public address identity is not carried by the address alone. It is carried by supporting evidence. Reverse DNS tells other systems how an address names itself. RPKI and ROAs help route origin validation systems determine whether an autonomous system is authorised to originate a prefix. Route acceptance by networks and platforms determines whether traffic will reach the new location. Registry contact and resource data help establish who is responsible for the number resource. Each layer is technical. Each also has commercial meaning in a cloud migration.
Reverse DNS is a good example because it is often treated as minor housekeeping until it becomes a blocker. Mail systems, abuse desks, enterprise security tools and compliance checks may inspect reverse names. A move from provider-owned addresses to another provider's pool can change the reverse identity in ways that affect trust. A move using a customer-owned prefix can preserve or control that identity if delegation and operations are properly arranged. If the customer never understood who controlled reverse DNS, it discovers the dependency at the worst moment. The cost is not the DNS record. It is the loss of continuity that the record represented.
RPKI and ROAs are similarly important, though in a different way. In cloud BYOIP settings, route-origin compatibility can decide whether a provider will advertise a customer prefix and whether other networks will accept the route. A customer may need a ROA that authorises the provider's autonomous system to originate the prefix, or may need to remove or adjust conflicting authorisations. The precise requirement depends on the provider and deployment model, and product details change. The economic point is stable: route-origin evidence has become an admission credential. A platform that helps customers navigate it supplies value. A platform that controls the process also gains timing leverage.
Route acceptance adds another layer of market power. Even if a registry record is accurate and a ROA is technically valid, the route must be accepted by networks that filter prefixes, enforce minimum sizes or apply their own policies. Cloud providers have the scale and operational relationships to manage this at large volume. Smaller providers may be more exposed to filtering disputes, reputation issues or slow propagation. Customers observe this as reliability. They may conclude that a major platform is the only practical place to carry certain public identities, even when the registry does not say so. Platform scale then converts technical coordination capacity into commercial advantage.
The policy lesson is not that every route should be accepted or that every reverse delegation should be frictionless. Bad data and bad routing can harm the wider internet. The lesson is that portability depends on evidence that can be carried across settings. If reverse DNS control, registry contacts, route-origin authorisation and routing intent are scattered or unclear, the customer cannot easily compare providers. It must ask each platform to interpret the evidence for it. The platform with the best product team becomes the practical judge of the customer's address future.
RIPE NCC already operates key parts of this evidence environment through registry records, the RIPE Database, RPKI, reverse DNS and routing or measurement information. The useful direction is to make these signals easier to audit for portability without turning them into permission slips for every commercial move. A customer should be able to produce a clear packet of evidence: this is the holder, this is the authorised maintainer, this is the reverse status, this is the current route-origin intent, this is the relevant route history, and these are the contacts responsible for change. If that packet is portable, cloud admission remains a product process rather than a dependency trap.
Reputation memory and enterprise allowlists
IPv4 scarcity gives addresses price. Reputation gives them memory. The public internet remembers which addresses have sent mail, hosted services, attracted abuse complaints, appeared in fraud systems, passed penetration tests, served APIs or been embedded in partner integrations. Some of that memory is formal. Some is informal. Some sits in commercial threat-intelligence products. Some sits in a customer's own allowlists or in the change-control documents of its partners. A cloud provider that supplies the address also supplies part of the customer's history.
Reputation memory matters because exit forces a customer to choose between carrying its existing public identity and starting again. If the customer used provider-owned addresses, it may not be able to carry that identity to another provider. It must ask partners to update allowlists, convince security systems to accept new ranges, monitor false positives, explain changes to regulators, re-run tests and handle support incidents. For a consumer website this may be manageable. For payment processing, public administration, healthcare integrations, industrial systems, supply-chain portals or regulated reporting, the change can be slow and politically costly.
Enterprises often underestimate this because allowlists are decentralised. A central architecture team may know the public endpoints. It may not know every partner that has pinned an address, every legacy system that lacks DNS flexibility, every firewall rule written by a subsidiary, or every public-sector platform that requires a ticket to update access. The cloud provider's address is therefore quietly reproduced outside the provider. The customer does not merely use the provider's pool. It trains its ecosystem to recognise the provider's pool as its own face.
This is a powerful form of bargaining leverage. The provider does not need to threaten the customer. It only needs to be the default source of a public identity that outsiders have learned to trust. Renewal negotiations then take place under the shadow of operational disruption. The cost of switching is not only the provider's migration bill. It includes the customer's reputational reset with hundreds of counterparties. The larger and more regulated the customer, the more costly that reset becomes.
Portable prefixes can reduce this problem, but only if they are prepared early. If the customer brings its own address range into the cloud from the start, it can preserve external identity across hosting changes. Partners may still need to adjust routes, certificates, DNS or security expectations, but the basic address can remain. That makes the customer less dependent on a provider's pool. It also gives the customer a stronger position in price and service negotiations. The credible ability to leave is often more important than the act of leaving.
RIPE NCC cannot manage reputation memory. It should not decide whether an address is trusted by a bank, a mail provider or a public-sector gateway. But it can help make continuity claims more credible. Accurate registration, clean contact records, stable reverse delegation and coherent route-origin information can support the customer's assertion that a public identity is genuinely under its control and can be moved responsibly. In a scarce market, that proof is part of the customer's economic resilience.
Security coupling and the price of clean traffic
Cloud providers rarely sell public addressing alone. They sell it alongside firewalls, DDoS protection, web-application filtering, abuse handling, logging, identity controls, compliance reporting and managed network products. This bundle can improve security. Large platforms see attacks early, operate at scale and can absorb traffic that would overwhelm smaller networks. For many customers, provider-owned public addresses come with a security posture they could not reproduce alone. The bundle is valuable, and its value is one reason customers accept platform control.
Security coupling becomes a source of address power when the clean public identity of a service depends on staying inside the provider's protective system. A customer that moves away must not only move an address or change an address. It must recreate mitigation capacity, logging evidence, incident procedures, abuse contacts, compliance attestations and customer assurances. If the old address belongs to the provider, the customer may lose both the number and the security history attached to it. If the address is portable but the security service is not, the customer must coordinate a careful handover. Either way, the exit path is more complex than a routing change.
DDoS protection illustrates the economic logic. A provider can offer always-on mitigation that is deeply integrated with its public edge. A customer may not know how much of its availability depends on that integration until it tests another option. If the customer's address identity is provider-owned, a rival provider cannot simply inherit the trusted endpoint. If the customer uses BYOIP, the rival still has to admit the prefix, align route-origin evidence and provide comparable mitigation. The address, the route and the security wrapper become a single commercial package.
This package can be pro-competitive when it lowers entry costs for customers. A small firm can deploy globally with strong protection without negotiating transit, scrubbing centres and registry details. A public service can launch quickly. A software vendor can standardise operations. Yet the same package can become anti-portable when procurement treats it as an indivisible cloud service. If the tender asks for uptime and DDoS protection but not for exit evidence, the winning provider may supply a technically excellent service that leaves the buyer dependent on provider-owned public identity.
The remedy is better separation in evidence, not artificial separation in engineering. It would be absurd to tell platforms that they cannot integrate addresses and security. Integration is part of the value they provide. But customers should be able to see which parts of the bundle are portable, which are account-bound and which require new proof at exit. A resilience assessment should distinguish between "the service can be rebuilt" and "the public identity can be carried with acceptable risk." Those are different claims.
For RIPE NCC, the relevant issue is again the integrity of the public evidence layer. If a customer-owned prefix is used behind a cloud security product, the registry and RPKI data should make the customer's control clear. If reverse DNS or routing history will be used to support continuity claims, that evidence should be easy to retrieve and understand. The registry does not certify the security product. It preserves the resource evidence that lets a customer avoid confusing security convenience with permanent captivity.
Public procurement and regulated customers
Public-sector and regulated-customer procurement can amplify cloud-provider address power because such buyers often formalise operational choices into long contracts. A ministry, hospital system, university, bank, insurer or utility may procure cloud services through a framework that prizes security, resilience, auditability and vendor capacity. Those are legitimate concerns. Large providers often perform well against them. But if the procurement language treats public addressing as a bundled service without requiring portability evidence, the contract can harden dependence before anyone notices.
The problem is not negligence. Procurement teams are usually trying to reduce risk. Provider-owned addresses can look safer than customer-owned resources because the provider takes responsibility for provisioning, routing and operational support. BYOIP can look like a specialised exception that slows delivery. In a tender calendar, convenience has political value. A project that launches on time with provider pools may be celebrated. The exit problem appears years later, when the contract is up for renewal, a regulator asks for concentration-risk analysis, or a resilience exercise requires workload movement.
Regulated firms face a similar issue. Financial supervisors, data-protection authorities, public-audit bodies and sector regulators increasingly ask firms to manage outsourcing concentration, resilience and exit. Those discussions often focus on data location, contractual rights, operational recovery and critical services. Public address identity is less visible. Yet for many services it is part of resilience. If a payment API, public claims portal or operational dashboard is reachable only through provider-owned addresses that hundreds of counterparties recognise, the ability to rebuild compute elsewhere may not equal the ability to restore the service in practice.
Public cloud procurement can also influence the private market. When large government buyers accept provider-owned identity as normal, integrators, consultants and suppliers reproduce that norm. Templates spread. Security documents describe provider address ranges as acceptable. Allowlist procedures assume the platform pool. Smaller firms serving government customers then follow the pattern to reduce friction. A procurement decision becomes a market convention, and the convention increases the platform's bargaining power.
None of this means tenders should require every workload to use customer-owned prefixes. That would be wasteful and sometimes impossible. The better question is proportionality. High-dependence services should identify whether their public identity is portable, what evidence proves it, who controls reverse DNS, what route-origin changes are needed, which counterparties have allowlists and how long an address change would take. Lower-risk services can use provider-owned pools with a conscious acceptance of exit cost. The issue is not that every address must be portable. It is that important services should not discover non-portability only when they try to leave.
RIPE NCC can support this through clearer public evidence and education without becoming a procurement regulator. It can help buyers understand that registry records are not decorative. They are continuity infrastructure. The fact that the RIPE NCC region includes more than 75 countries makes this especially important. Public-sector maturity varies widely. Common, comprehensible evidence of resource control would help buyers and auditors ask the right questions even when they lack deep network teams.
Small providers and the asymmetry of proof
Cloud-provider address power is not only a contest between large platforms and large customers. It also affects small hosting firms, regional cloud providers, managed-service firms and specialised infrastructure suppliers. These firms may serve customers that need local support, data-sovereignty comfort, sector knowledge or pricing flexibility. They may be technically competent and close to the customer. Yet they often lack the global route reach, automated BYOIP product depth, security scale and procurement recognition of the largest platforms. Address portability evidence can either help them compete or leave them stuck behind private admission systems.
A customer that owns a clean prefix and can prove control can consider a smaller provider with less fear. It can ask the provider to advertise the range, maintain reverse DNS, align RPKI, support DDoS arrangements and document the exit path. The provider still must be capable, but the customer's public identity is not locked to the incumbent platform. By contrast, a customer that has built on a hyperscale provider's address pool may find that moving to a regional supplier means a painful public-identity reset. The regional supplier is then competing not only on service quality but against the memory of the incumbent's addresses in the customer's ecosystem.
The asymmetry of proof also affects negotiations. Large providers have teams that can interpret registry records, validate prefix control and guide customers through route-origin changes. Small providers may rely on manual processes. Customers may trust the large platform's admission decision more than their own records. If the platform says a prefix is not ready, the customer may assume the problem is the prefix rather than the platform's product conditions. If a smaller provider says the same evidence is usable, the customer may worry about risk. The private admission standard of the largest platform becomes a market benchmark, even where it reflects product design rather than universal routing truth.
This is not an argument for lowering routing standards. A market in which anyone can assert anyone else's prefix would be insecure. The point is that proof should not be needlessly platform-specific. If a resource holder has accurate registry data, maintained contacts, valid route-origin information and clear authorisation, that evidence should be intelligible to many providers. A smaller provider should not have to reverse-engineer a hyperscale platform's private checklist to convince a customer that the customer's own prefix is usable.
Address scarcity intensifies this asymmetry because customers that do not already hold IPv4 space may have no realistic path to independent public identity except transfers or leasing arrangements. The cost of obtaining a portable range can be high. The administrative burden can be unfamiliar. Provider-owned pools then appear as the rational choice. For many low-risk services they are. But when the customer's public endpoint is strategic, the absence of portable identity gives the incumbent provider a claim on future bargaining surplus. The price of address convenience is paid later through reduced options.
A healthy RIPE NCC evidence environment would not guarantee small-provider success. It would simply make portability less mysterious. The registry should not tilt the market toward any class of provider. But it should make resource control clear enough that customers can compare offers on service merits rather than on fear that their public identity cannot survive movement. In institutional terms, the ledger should reduce the premium on being the platform that already hosts the customer's address.
Why cloud address power is not the same as address hoarding
It is tempting to measure cloud address power by counting who holds IPv4 resources. Inventory matters. Large pools allow platforms to supply customers instantly, absorb growth and maintain regional products. IPv4 prices make those pools valuable balance-sheet assets even when they are not reported in a way that isolates address economics. But inventory is only one part of power. The more durable power comes from turning address use into a managed relationship.
A provider with fewer addresses but strong account integration can still create dependence. If customers attach the provider's addresses to critical services, write them into partner allowlists, rely on the provider's reverse DNS practices, use its security edge and build automation around its APIs, the provider gains leverage even without dominating the entire address market. Conversely, a large address holder that does not mediate customer identity may have less lock-in effect. The commercial question is not just "who has the numbers?" It is "who controls the evidence, timing and operational rituals that make those numbers usable?"
This is why BYOIP can coexist with lock-in. A provider may permit customers to bring prefixes and still preserve leverage through account terms, regional limitations, review timelines, route-origin requirements, security coupling and exit procedures. Some of those constraints are justified. Cloud networks are complex, and careless prefix admission can create hijack risk, instability or abuse. But the existence of a portability product should not end the analysis. The real test is whether the customer can use the same evidence to obtain credible service from more than one provider within a commercially relevant time.
Address hoarding also implies a simple villain. Cloud address power is more diffuse. Customers choose convenience. Integrators favour repeatable designs. Security teams prefer known platforms. Procurement rewards delivery. Regulators sometimes ask for resilience but leave public identity vague. Registries maintain evidence but may not package it for portability. Each actor behaves sensibly within its own domain. The combined result can still be reduced customer choice.
The economics resemble other markets where a common resource becomes embedded in a service wrapper. A phone number, domain name, payment credential or identity certificate may be portable in principle, but switching depends on records, proofs, contracts, propagation and third-party recognition. The holder does not care that a right exists in theory if exercising it creates weeks of disruption. The cloud provider that makes the initial setup seamless and the later exit intricate has gained power through process rather than ownership alone.
For RIPE NCC, this distinction is vital. If the problem were merely hoarding, the answer might be redistribution or rationing. That is not the right path for a regional internet registry whose strength lies in neutral coordination. If the problem is evidence portability, the answer is better records, clearer signals and more reliable continuity tools. The ledger should not become a market planner. It should make it harder for scarcity and confusion to be monetised as captivity.
The institutional economics of a thin ledger
A thin ledger can be a strong institution when it does its narrow job well. The RIPE NCC registry does not need to decide the economic fairness of every cloud contract to affect market outcomes. By maintaining accurate records and related evidence systems, it shapes the cost of verification. Verification cost is a hidden tax on switching. When it is low, customers can test offers, move services and discipline providers. When it is high, customers stay with incumbents because proving the right to move is too slow, too technical or too uncertain.
This is a classic institutional-economics problem. Markets work better when property-like claims, responsibilities and authorisations can be verified at low cost. IPv4 addresses are not ordinary property, and the registry should avoid language that suggests absolute ownership. Yet customers and providers still need stable expectations. Who is responsible for the resource? Who may authorise a route? Who controls reverse delegation? Who should receive abuse contacts? Which record is current? If the answers require bespoke interpretation, the party with the larger legal and technical department wins.
Cloud platforms thrive by lowering many transaction costs. They reduce the need to negotiate hardware, colocation, transit, DDoS mitigation and routine operations. But they can raise another transaction cost: the cost of leaving with public identity intact. A thin public ledger counterbalances this by making the customer's independent claims easier to establish. It does not abolish platform contracts. It gives the customer a credible outside option.
The distinction between ledger and gatekeeper is therefore not a slogan. A gatekeeper grants permission according to discretion. A ledger records facts and authorisations in a way that lets many parties coordinate. If RIPE NCC tried to dictate cloud admission, it would weaken its neutrality and create new disputes. If it neglected the portability value of its records, it would leave customers dependent on private gatekeepers. The middle path is disciplined: keep the registry thin, but make the evidence clean, current and easy to carry.
This also protects running-network continuity. The internet is not improved by abrupt formalism that treats every administrative defect as a reason to break service. Customers, providers and networks need continuity while records are improved. But continuity should not become an excuse for stale data that traps holders in old arrangements. The registry's task is to support responsible movement: enough stability that services do not fail, enough clarity that dependence can be challenged, and enough neutrality that it does not pick commercial sides.
In the RIPE NCC region, this approach is particularly relevant because cloud adoption intersects with varied legal systems, public procurement cultures and legacy address histories. A single heavy rule would misfire. A better evidence layer would travel across these differences. It would let a hospital in one country, a fintech in another, a regional cloud in a third and a public ministry elsewhere use the same basic proof when discussing address portability. That is the quiet power of a good ledger.
What a portability evidence standard should contain
A useful portability evidence standard would not require RIPE NCC to certify that a cloud provider must accept a prefix. It would describe the evidence that a resource holder should be able to assemble before, during and after a cloud deployment. It would be practical, not grand. It would help procurement teams, auditors, providers and customers distinguish between provider-owned identity and customer-controlled identity. It would give smaller buyers a checklist that does not depend on a hyperscale account team.
The first element is resource-holder clarity. The customer should be able to show the current registry record, the maintained contacts, the responsible organisation and the authority chain for changes. If the resource is held through a sponsoring LIR or related entity, the customer should understand what that means for cloud admission and exit. Ambiguous commercial arrangements should be clarified before a critical service relies on the range. A name in a database is not enough if no one knows who can authorise change.
The second element is route-origin readiness. The holder should know which autonomous system is authorised to originate the prefix, how ROAs are maintained, what maximum length is allowed, and how the intended cloud provider's origin fits the record. This does not mean every customer must become a routing expert. It means the evidence should be accessible enough that a cloud admission check is not the first time the customer discovers a conflict. Route-origin validation has become too important to leave as an afterthought.
The third element is reverse DNS control. Customers should know who controls reverse delegation, what naming conventions are used, how changes are made and how those changes affect mail, security tools and partner checks. Reverse DNS is not a branding exercise. It is part of the public identity stack. If a provider-owned address has provider-controlled reverse naming, the customer should recognise that as a portability trade-off. If a customer-owned prefix has customer-controlled reverse naming, it should be documented as a continuity asset.
The fourth element is route and reputation history. A customer preparing to move should be able to review where its prefix has been seen, how it has been originated, and whether any reputation issues could affect admission or acceptance. RIPE NCC's routing and measurement information can support this analysis without pretending to judge the commercial quality of a provider. The aim is to reduce surprises. A surprise about route history during a migration window is an avoidable cost.
The fifth element is account-exit procedure. If the prefix is used in a cloud platform, the customer should document how to withdraw it, move it to another account, change origin authorisation, update security products, preserve logs and handle the interval between providers. This is partly outside the registry. But registry evidence should be referenced in the procedure. The customer should know which public records must change and which must remain stable.
Such a standard would be modest but useful. It would not solve cloud concentration. It would not make IPv4 abundant. It would not eliminate the legitimate security reviews that providers perform. It would, however, reduce the private mystery around address portability. In a scarce market, reducing mystery is a competitive act even when the institution remains neutral.
A constructive agenda for RIPE NCC
A constructive RIPE NCC agenda would begin with portability visibility. The registry could make it easier for members and resource holders to see, in one place, the evidence likely to matter in a cloud admission or exit process: holder information, maintained contacts, reverse DNS status, RPKI/ROA status, observed route origins, and relevant operational warnings. This would not be a certification. It would be a readiness view. Its value would lie in reducing the cost of asking the right questions.
The next step would be guidance written for buyers, not only network specialists. Many cloud decisions are made by procurement, risk, legal and digital-delivery teams. They need language that distinguishes provider-owned addresses from customer-controlled prefixes without requiring them to become routing engineers. A short public guide could explain why "static IP" is not the same as portable identity, why reverse DNS and ROAs matter, and how address decisions affect exit. Such guidance would be especially useful for public-sector and regulated buyers.
RIPE NCC could also encourage standardised evidence packages for BYOIP and exit planning. Providers would remain free to set product rules, but a common evidence package would help customers compare requirements. It might include current registry data, authorisation contacts, RPKI state, intended origin ASNs, reverse DNS control, and change procedures. If major providers still ask for additional checks, that is their right. But the customer would start from a common proof base rather than from uncertainty.
Measurement can help too. RIPE NCC's routing and measurement information can illuminate how prefixes are originated, where changes occur and how visible routes are during migration. The goal should not be to score providers politically. It should be to help holders understand operational history and risk. A customer that can see its route history is better prepared to discuss admission with a cloud platform or a regional provider. A customer that cannot see it must rely on whoever offers the most confident interpretation.
Finally, RIPE NCC can convene without commanding. It can bring cloud providers, regional networks, enterprises, public-sector buyers and security teams into practical discussion about portability evidence. The agenda should be narrow: reduce avoidable ambiguity, improve continuity, and keep registry proof usable across platforms. Such convening would be consistent with a coordination role. It would not require the registry to judge market power directly.
The likely objection is that this agenda is too modest for the scale of cloud concentration. But modesty is a virtue here. The registry cannot make IPv4 abundant, and it should not become a competition authority. What it can do is make sure the shared evidence layer works for the weaker party in a portability dispute. That is not everything. It is still meaningful. Many forms of market power survive because the cost of proving an alternative is too high. Lowering that cost is a legitimate registry contribution.
The thin ledger and the cloud account
The cloud account is a remarkable commercial invention. It turns infrastructure into a set of programmable services. It lets customers consume global networks without building them. It wraps complexity in APIs and support contracts. It has allowed many organisations in the RIPE NCC region to deploy services that would once have required far more capital and expertise. The criticism of cloud-provider address power should not obscure that achievement.
But the account is not the same as the internet's public ledger. The account is a relationship with a provider. The ledger is a coordination tool used by many parties. When public address identity is absorbed too completely into the account, the customer may gain convenience while losing independent standing. It can act quickly inside the platform but struggle to prove itself outside it. That is the central economic trade-off.
IPv4 scarcity sharpens the trade-off. If public addresses were abundant, a customer could more easily start again. Scarcity makes old identity valuable. It makes address histories sticky. It makes provider pools attractive and portable ranges costly. It makes every admission check more consequential. Scarcity does not decide who should win the cloud market, but it increases the value of every institution that can lower switching costs. RIPE NCC is one of those institutions because its records are part of the proof chain.
The right conclusion is therefore neither platform fatalism nor registry activism. Cloud providers will continue to supply public addresses, BYOIP products and security bundles. Customers will continue to choose convenience. Some workloads will not justify portable identity. Competition authorities, procurement bodies and regulators will address broader concentration questions through their own tools. RIPE NCC's responsibility is narrower: keep the resource evidence accurate, continuous and usable enough that customers can prove their public identity when it matters.
If the ledger is strong, a customer can ask a cloud provider for service without surrendering its future. It can bring a prefix, show control, align route-origin evidence, manage reverse DNS and preserve reputation across movement. It can decide consciously when provider-owned pools are worth the exit cost. It can make procurement compare not only today's uptime but tomorrow's bargaining position. The result is not perfect freedom. It is a more honest market.
If the ledger is weak, cloud providers do not need to seize anything. They can let scarcity, uncertainty and customer inertia do the work. Provider-owned pools become the default public face. BYOIP remains a specialised route for those with enough expertise. Allowlists and reputation memory accumulate. Security bundles deepen dependence. Public-sector frameworks normalise the pattern. At renewal, the provider sells not only compute and security but relief from the disruption that leaving would cause.
That is the economics of cloud-provider address power in the RIPE NCC region. It is not just address volume. It is the conversion of scarce public identity into account-bound service, private admission and procurement habit. The answer is not to turn RIPE NCC into a cloud policeman. It is to make the common ledger do its quiet job well enough that portability is real before it is urgently needed. In a scarce IPv4 world, that quiet work is one of the few practical checks on address dependence.