Summary
- Datacentre address demand is not the same as datacentre capacity demand: a powered rack, cage or edge site becomes useful only when public endpoints can be trusted by customers, upstreams, security services and counterparties.
- In the RIPE NCC region, exhausted IPv4, uneven legacy holdings, transfer pricing and leasing options make public-address inventory a working-capital problem for colocation, hosting, bare-metal and SaaS-facing infrastructure.
- Tenants still need IPv4 despite IPv6 and NAT because procurement files, partner allowlists, mail reputation, dedicated appliances, monitoring, managed firewalls and public-service continuity still depend on stable public addresses.
- Registry evidence is the acceptance substrate: RIPE Database records, holder authority, reverse DNS, abuse contacts, RPKI/ROAs and route-origin credibility help decide whether a tenant can go live without reputational drag.
- Datacentres are not registries, but they become indirect gatekeepers when address stock, reputation and evidence determine which tenants can be admitted, expanded, migrated or allowed to exit cleanly.
- RIPE NCC should not plan datacentre growth; it should make the ledger accurate, predictable and portable enough that scarcity cannot be quietly converted into private control over activation, continuity and customer movement.
The onboarding queue where the missing input is public evidence
The most revealing queue in a datacentre is not always the queue for power. It may be the quieter queue behind a sales desk, a provisioning board and a network engineer's calendar. A colocation provider has sold cabinets in a well-connected hall. The power reservation is signed. Cooling is available. The cross-connect order has moved from indicative to scheduled. A carrier meet-me room offers enough choice to make the brochure look serious. Remote hands can receive the first shipment. The cage is physically ready.
Then the tenant asks the question that turns the lease into a public-service problem. How many IPv4 addresses can be ready for first traffic? Are they clean? Which holder record will identify the range? Can reverse DNS be changed before the migration window? Will a ROA support the intended origin? Which abuse desk will receive complaints? Are the addresses already damaged by mail history, security reports or geolocation errors? If the customer has to leave in two years, can the public face of the service move, or will every endpoint be trapped in the provider's pool?
That is the moment when datacentre capacity divides into two markets. The first is facility capacity: megawatts, racks, floor load, security, cooling, cabling, cross-connects and physical access. The second is addressable-endpoint capacity: the credible public network identity that lets a tenant expose services to customers, suppliers, regulators, security tools and other networks. A provider can have the first without having enough of the second. When that happens, the facility may be ready while revenue is still waiting for public-address evidence.
The RIPE NCC region makes this tension visible because it contains dense colocation hubs, national hosting markets, enterprise estates, public-sector procurement, edge racks, internet exchange ecosystems and a long history of IPv4 distribution. RIPE NCC serves Europe, the Middle East and parts of Central Asia. Its IPv4 free pool was exhausted in 2019. Its membership and wider community contain telecom operators, hosters, cloud firms, enterprises, public networks, universities, registries, security companies and small access providers. The region has both large campuses and narrow national markets where a modest address range can determine whether a local service is viable.
Datacentre address demand is therefore not a simple count of addresses per server. It is the demand for credible public reachability. A bare-metal hoster may need dedicated IPv4 for customer machines. A SaaS tenant may need stable source addresses for API customers. A managed firewall provider may need public interfaces for appliance edges. A public-service contractor may need ranges that a government buyer can record in a continuity file. A hosting reseller may need separation so one tenant's abuse history does not contaminate another tenant's mail. An edge rack may need just enough public space for management, monitoring, DDoS diversion and customer portals. Each case turns scarce addresses into operating inventory.
This is not a story about a cloud account controlling a customer's public identity. Nor is it mainly a story about cable reroutes, peering politics or the closing paperwork of a transfer. Those themes matter elsewhere. The datacentre version begins in the onboarding queue. It asks why an apparently finished physical product can still be unable to accept the next customer. The answer is that IPv4 scarcity has moved from the policy background into the revenue machinery of the hall.
Facility capacity and addressable-endpoint demand are different
A datacentre sells a physical promise, but many tenants buy a public operating surface. Facility capacity is visible and measurable. It can be toured, financed, insured, photographed and commissioned. Addressable-endpoint demand is less visible. It appears in the customer's security questionnaire, procurement appendix, abuse escalation path, mail deliverability plan, RPKI check, reverse-DNS request, allowlist spreadsheet and migration schedule. It is often discovered late because it looks like a network detail until it blocks activation.
The distinction matters because facility capacity can scale in large units while public endpoints are consumed in awkward ones. A new hall may add thousands of cabinets. A tenant may need a /29 for a pair of firewalls, a /27 for a managed appliance cluster, several small pools for customer segregation, a larger range for bare-metal provisioning, or reserved swing capacity during a move. The shapes do not necessarily match. Address inventory must be held in sizes that fit operational use, not merely counted as a total.
Addressable demand also has quality grades. A range can be technically routable yet commercially weak. Prior spam, malware reports, stale reverse names, wrong geolocation, weak abuse history, conflicting route-origin signals or unclear holder authority can make addresses hard to sell to regulated customers. A high-value tenant may reject a cheap range because the public identity would take too long to repair. Another tenant may accept the same range for a low-risk product. Scarcity is therefore not just quantity. It is quality, evidence and fit.
Colocation sharpens the distinction because the provider may not be the final service operator. A tenant brings equipment, staff, software and customers. The datacentre supplies space, power, connectivity options and often address assistance. The tenant may use its own ASN, the provider's transit, a DDoS provider, a managed router, a public cloud link or a blend of all these. The commercial question becomes: whose evidence will the outside world recognise? If the tenant wants to originate a prefix, route-origin authorisation must align. If the provider announces the range, the tenant still needs confidence that the arrangement will survive renewal, abuse complaints and exit.
Bare-metal hosting is the clearest address converter. The provider sells dedicated machines, but the customer expects a public endpoint attached at provisioning speed. If the product is aimed at developers, security firms, gaming companies, media platforms or enterprise labs, the address pool becomes part of fulfilment. A bare-metal machine without a clean public address is not the same product. It is metal awaiting admission to the internet economy. The faster the sales model, the more costly an address shortage becomes.
SaaS and managed services use fewer addresses per compute unit, yet the addresses they use can be more sensitive. API customers may lock down source ranges. Banks may record supplier endpoints. Security teams may monitor known public names. Customer portals may need continuity through audits. A change of public address can trigger testing, tickets and executive concern out of all proportion to the number of addresses involved. For such tenants, the address is a trust anchor, not a commodity input.
Edge racks add another variation. An edge deployment may be small, but its public reachability can support local content, monitoring, command systems, recovery access, customer breakout, low-latency services or DDoS diversion. In some national markets, a few addresses can decide whether a regional hoster can offer a credible service near customers rather than push everything into a distant campus. The scarce input may be modest in size and large in local effect.
The practical result is that a datacentre operator must plan addressable-endpoint demand separately from floor demand. A sales forecast by cabinets is not enough. The provider must ask which tenants need public IPv4, which can share, which require dedicated ranges, which have reputational sensitivity, which bring their own address space, which need exit rights, which need reverse DNS, and which require route-origin support before traffic moves. Without that analysis, the hall may look full in the pipeline and still fail at activation.
IPv4 scarcity turns addresses into working capital tied to racks
Once IPv4 is exhausted, public addresses behave less like a free technical setting and more like working capital. A datacentre operator, hoster or managed-service provider must obtain inventory before final demand is certain. It must finance that inventory, reserve it, cleanse it, allocate it, reclaim it and decide how much idle stock is necessary to keep future revenue from stalling. The scarcity cost is tied to racks because the tenant's physical footprint cannot be fully monetised unless the public endpoint plan is ready.
The working-capital problem begins with timing. Tenants rarely request addresses in a smooth curve. A government supplier may delay for months and then need a cutover in a fixed week. A bare-metal customer may start with a small pool and then expand rapidly. A SaaS firm may add a region because a major customer asks for data locality. A security incident may require new ranges to separate traffic. A migration may need old and new addresses to run in parallel while customers update allowlists. If a provider buys or leases only after each need is confirmed, it may miss the revenue window.
Holding stock carries cost. Purchased addresses tie up capital that could have gone into power contracts, staff, cross-connect capacity or sales. Leased addresses create recurring expense and renewal exposure. Old ranges require contact maintenance, reverse-DNS cleanup, reputation work and sometimes corporate-history review. Provider-assigned pools must be kept clean and segmented. Returned ranges need quarantine before reuse. The address file becomes a balance-sheet and operations file at the same time.
There is also a shape problem. A provider with a large aggregate count may still lack the right fragments. Some customers need a contiguous block that can be routed cleanly. Others need several smaller pools that do not share history. Some need ranges under the provider's direct control. Others require their own holder authority or a clear authorisation path. Some need public IPv4 only for management and customer entry points, while internal systems can use private addresses or IPv6. Inventory that is abundant in the wrong shape can still delay revenue.
The temptation is to overbook the address pool. Shared egress, NAT, proxy layers, load balancers and private connectivity all help conserve IPv4. They are useful tools, and in many cases they are the right tools. But overbooking converts scarcity into hidden performance, attribution and exit risk. If too many tenants share the same public identity, abuse complaints become harder to attribute, mail reputation becomes harder to protect, customer logs become less clear and a future move requires disentangling many services from one public face.
Another temptation is to push scarcity cost downstream without naming it. A provider can offer low cabinet pricing and then charge heavily for public IPv4. It can advertise rapid onboarding while quietly rationing addresses. It can supply leased ranges without explaining renewal risk. It can make the tenant responsible for reputation remediation after assignment. It can offer "dedicated" public addressing that is dedicated in daily use but not portable in any meaningful exit. These choices may be legal and sometimes rational. They are also how scarcity becomes a private toll on activation.
The RIPE NCC record matters because it reduces argument around the scarce input. Accurate holder data, clear organisation records, maintained contacts, reverse-DNS paths and route-origin evidence make inventory more usable. If a provider has to explain every range from scratch to each tenant, upstream, DDoS provider and enterprise customer, address stock loses liquidity. If the ledger is coherent, a range can be assessed faster, transferred with less uncertainty and integrated into a service file with fewer bespoke assurances.
Working capital also includes swing capacity. A tenant moving from one provider to another often needs overlap. Old services must continue while new ones are tested. Customer allowlists must change gradually. Mail reputation may need warming. Monitoring systems must be updated. Security teams may need parallel logs. Without spare addresses for the transition, the tenant is forced into a sharp cutover or a provider-owned stopgap. Swing capacity is costly precisely because it is temporary, yet it can decide whether a migration is safe.
Datacentres that treat address stock as working capital will differ from those that treat it as a static network pool. The serious operator will know which ranges are clean, which are leased, which are transferable, which are suited to public-service customers, which are safe for mail, which need remediation, which have reverse-DNS constraints, and which have route-origin evidence ready. In a scarce-number economy, that file is part of the operating margin.
Why IPv6 and NAT do not remove the datacentre IPv4 problem
The obvious answer to IPv4 scarcity is IPv6. The obvious engineering tool for conservation is NAT. Both matter. Neither removes the datacentre address problem in the period that matters for commercial activation. Tenants buy services in a world where customers, partners, appliances, banks, regulators, email systems, old software and security controls still rely on IPv4. A provider can design for IPv6 while still needing enough credible IPv4 to sell the next rack.
IPv6 helps most when both sides of a service are modern and under competent administration. It is excellent for internal design, new platforms, end-to-end reachability, private networks that do not want address conflict, and future resilience. It should be part of any serious datacentre strategy. But many customer-facing services cannot simply declare the IPv4 era over. Supplier portals, payment integrations, remote management tools, anti-fraud systems, VPN appliances, legacy industrial equipment and partner firewalls often remain IPv4-dependent. The tenant's service must work for those counterparties, not for an idealised network.
NAT reduces public address consumption by sharing addresses across many private endpoints. It is indispensable at scale. Yet NAT is not free. It can weaken attribution, complicate abuse handling, compress many customers into one reputation surface, create logging burdens, make customer allowlists less meaningful and turn exit into a translation exercise. Carrier-grade NAT is familiar in access networks, but datacentre tenants often need more precise accountability. A hospital supplier, payment processor or government contractor may not accept a service whose public identity is a crowded egress pool with a long abuse history.
Dedicated appliances explain the residual demand. Managed firewalls, load balancers, VPN concentrators, DDoS interfaces, monitoring collectors and customer-specific security gateways often need public addresses even when most servers sit behind private networks. The public address count may be small, but the value attached to each address is high. A tenant may be able to run thousands of internal processes without public IPv4, then still require a handful of trusted public endpoints to make the product usable.
Mail is a harsher example. Many datacentres prefer not to support heavy mail workloads because reputation damage is expensive. Yet some hosters, SaaS firms and enterprise tenants still need outbound mail or trusted notification services. Mail systems remember address history. Reverse DNS, SPF, DKIM alignment, complaint rates and blacklist status matter. A newly assigned IPv4 range can carry old damage; a NAT-shared pool can spread one tenant's behaviour across many. IPv6 support in mail is improving, but IPv4 reputation still shapes deliverability for many customers.
Public-sector and regulated customers are even more conservative. They often embed source addresses in procurement records, accreditation files, vendor reviews, continuity exercises and incident response playbooks. The address may be a small field in a spreadsheet, yet changing it can require approvals across departments. NAT may work technically while failing the assurance test. IPv6 may be accepted for part of the service while the contractual control still asks for IPv4 source addresses. The datacentre provider must satisfy the buyer's actual audit environment.
Peering and cross-connect arrangements also preserve IPv4 demand. A tenant may order private connectivity to a carrier, cloud, exchange or customer, but still need public addresses for failover, monitoring, remote access, customer onboarding or public APIs. Cross-connects reduce internet exposure for selected traffic; they do not eliminate public-service identity. In fact, a richer connectivity environment can increase demand for credible public endpoints because more tenants use the hall as an operating base rather than a simple server room.
The right conclusion is not pessimism about IPv6. It is discipline about transition economics. IPv6 and NAT are conservation tools, not proof that IPv4 scarcity has ceased to govern activation. A datacentre that ignores IPv6 is making its future harder. A datacentre that assumes IPv6 removes the need for scarce IPv4 is making its present harder. The commercial period between those two errors is where RIPE NCC's ledger, transfer recognition and evidence services matter most.
Registry evidence is the substrate for acceptance
Public addresses are trusted through layers of evidence. The tenant may care about the contract. The upstream may care about route policy. The DDoS provider may care about origin authority and abuse history. The enterprise customer may care about allowlists and supplier records. Mail receivers may care about reverse DNS and reputation. Security vendors may care about prior behaviour. A registry record does not settle all of these questions, but it supplies the public anchor around which many of them are organised.
In the RIPE NCC region, the RIPE Database, resource-holder records, contact roles, reverse-DNS arrangements and RPKI support form part of the acceptance substrate. A holder record shows who is recognised in the registry system. Contact data and abuse roles show where complaints and administrative questions should go. Reverse DNS lets naming align with service use. RPKI and ROAs help state which origin ASN is authorised to announce a prefix. Transfer records and account authority help counterparties understand whether a range can move or be updated.
Each element has a commercial effect. A tenant with clear holder authority can negotiate with more confidence. A provider with current abuse contacts can answer complaints without looking evasive. A range with aligned reverse DNS can pass mail and security checks faster. A ROA that matches the intended origin can reduce route-acceptance friction. A transfer that is recognised in the registry can be incorporated into financing, customer assurance and operations. Evidence reduces the cost of being believed.
The opposite is also true. Stale records turn address inventory into disputed inventory. A legacy range with old names, retired contacts, weak corporate continuity or ambiguous delegated authority may be valuable in theory and slow in practice. A leased range without clear authorisation may work until a customer asks whether the holder can withdraw cooperation. A provider-assigned pool with generic reverse names may be fine for simple web traffic and weak for a regulated application. A missing or conflicting route-origin statement may force engineering teams to choose between delay and risk.
Reputation sits beside the registry record but depends on it indirectly. Security vendors, mail systems and customers may not read every registry field, yet they care about accountability. If abuse reports reach a real desk, if names match the service, if route-origin evidence is coherent and if the holder can correct records, reputation damage can be managed. If the public record is messy, remediation becomes slower. A scarce address with bad history is not merely a technical burden; it is a reputational liability attached to inventory.
The acceptance substrate becomes more important when there are several parties in the chain. A colocation provider may rely on a lessor for address stock, a carrier for announcement, a DDoS provider for scrubbing, a tenant for service operation and a public-sector customer for acceptance. Each party wants to know that the address range is not a fragile private promise. The registry ledger does not replace contracts among them. It gives them a common factual base, reducing the number of private assurances needed before traffic moves.
That common base is why a thin ledger can have large economic value. RIPE NCC should not decide whether a datacentre tenant deserves to grow. It should not rank business models or allocate scarce numbers according to fashionable industrial goals. Its value lies in maintaining public evidence that is stable enough for others to rely on. When the ledger is accurate, non-discretionary and portable, private markets can make decisions without converting every address question into a bilateral test of power.
The phrase "route acceptance" captures the point. A route may be technically announced, but it must also be accepted by other networks and risk systems. RPKI and ROAs are not a full theory of trust; they are a crucial evidence layer. Reverse DNS is not a guarantee of virtue; it is a naming and responsibility layer. Abuse contacts are not punishment; they are a response layer. Holder records are not a business licence; they are a stewardship layer. Together they form the public evidence that lets a datacentre tenant become visible without depending solely on the provider's private assurances.
Datacentres become indirect gatekeepers
Datacentres are not registries. They do not create globally unique number resources, and they should not pretend to be neutral public authorities. Yet they become indirect gatekeepers because they decide how scarce address inventory is packaged, priced, documented and attached to tenants. They choose who receives dedicated public ranges, who must share, who can bring address space, who gets reverse-DNS support, who receives route-origin assistance, who bears reputation remediation and who can leave with continuity.
This gatekeeping is not always abusive. A provider must protect its network, its other tenants and its reputation. It may refuse high-risk customers, ration scarce IPv4, require strong abuse procedures or charge for dedicated ranges. It may prefer shared pools for simple products and reserve cleaner ranges for sensitive services. These are normal commercial decisions. The problem arises when scarcity cost is hidden, when portability is overstated, or when evidence is controlled so tightly that the tenant cannot price dependence.
Onboarding is the first gate. A tenant may be accepted into the physical hall but not yet accepted into the public network surface. The provider may ask for justification before assigning IPv4. It may require the tenant to use NAT. It may charge more for additional public addresses. It may deny reverse-DNS delegation. It may delay route-origin support until after payment or account review. Each decision may be defensible on its own. Collectively, they determine whether the tenant can sell its own service.
Expansion is the second gate. A bare-metal hoster that cannot obtain more clean IPv4 may have to slow sales even if racks and power are available. A SaaS provider may have to turn down a customer that demands dedicated endpoints. A public-service supplier may be unable to add a recovery site. A small hoster may be pushed toward a larger platform because the larger firm has more address stock. Scarcity thus influences industrial structure. It can favour providers with older holdings, stronger financing or better access to leased ranges.
Exit is the third gate. If a tenant's public identity sits entirely in the provider's pool, leaving is costly. Customer allowlists, reverse DNS, incident histories, reputation and monitoring records may all need to change. If the tenant brought its own space but depended on provider support for route-origin evidence, the exit may still require coordination. If the provider used leased ranges without a clear handover path, the tenant may discover that continuity was rented, not owned. Exit cost is not an accidental side effect; it is one way address scarcity turns into bargaining power.
DDoS and security services add another gate. Many tenants need scrubbing, web-application protection, managed firewalls or security monitoring. These services often require public-address coordination, route changes, GRE tunnels, BGP sessions, reverse-DNS checks, customer verification or reputation review. A datacentre that can integrate address evidence with security services can activate tenants faster. A tenant that cannot produce credible evidence may be pushed toward provider-owned security bundles. Again, the issue is not wrongdoing. It is who controls the evidence needed for acceptance.
Enterprise customers create a final gate from the demand side. A tenant may be ready to use a datacentre, but its own customers may refuse a vague address plan. Large buyers ask for stable endpoints, abuse contacts, continuity procedures, data-location assurance and incident response paths. The datacentre provider may not sit in the buyer's meeting, yet its address policy decides whether the tenant can answer. The hall becomes an admission desk for trust it does not fully control.
Institutional legitimacy depends on keeping these private gates from becoming substitutes for the public ledger. A datacentre can manage its inventory and price scarcity, but it should not be the only party able to describe the tenant's public identity. A registry can maintain evidence without becoming a planner. The healthy boundary is simple: private providers decide what they sell; the public ledger makes stewardship, authority and routing evidence portable enough that tenants are not trapped by obscurity.
Transfers, leases and reputation decide who carries scarcity cost
The supply chain for datacentre IPv4 demand runs through transfers, old holdings, leasing arrangements, reclaimed pools and internal conservation. Each path answers the same question differently: who carries the cost of scarcity? A provider that purchases addresses carries capital cost upfront and gains stronger control. A provider that leases carries recurring cost and renewal risk. A tenant that brings its own space carries administrative burden but keeps portability. A customer that accepts a shared pool pays later through dependence, reputational exposure or exit friction.
Transfers are the durable path when a provider expects continuing demand. They can convert underused address space into datacentre inventory with clearer authority and longer planning horizons. In the RIPE NCC region, transfer policy and registry recognition help make that possible. Yet transfers do not magically produce ready stock. A range may require due diligence, holder verification, agreement among related companies, contact updates, reverse-DNS transition, routing changes and reputation remediation. The price per address is only the visible part of the cost.
Legacy or older enterprise holdings are attractive and difficult for the same reason. They may be large, clean and underused. They may also carry stale records, old corporate names, missing staff, unclear internal authority or dependencies that have never been fully documented. A datacentre buyer may see potential inventory; a serious customer will ask whether the authority chain is clean enough to rely on. The older the address history, the more valuable the ledger becomes as a way of turning memory into usable evidence.
Leasing is flexible. It can support uncertain demand, temporary projects, swing capacity, trial customers, seasonal workloads or a growth period before a provider buys permanent stock. It can help small operators avoid tying up too much capital. It can also turn scarcity into hidden fragility. If the recognised holder remains elsewhere, who controls reverse DNS? Who creates or changes ROAs? Who answers abuse? What happens if the lease ends during a customer contract? Can the tenant disclose the arrangement to its own customer? Is there a documented path from leased use to transfer or replacement?
Leasing temptation grows when transfer prices rise. A provider under sales pressure may prefer a cheaper, faster arrangement and hope continuity questions do not arise. That can be rational for low-risk uses. It is dangerous for public-service customers, regulated tenants and products that sell dedicated infrastructure. The problem is not lease use itself. The problem is selling leased public identity as if it had the same continuity as provider-held or tenant-held space. Scarcity cost has not disappeared; it has been moved into renewal and evidence risk.
Reputation decides whether supply can be monetised. A leased or transferred block that is polluted by prior abuse may need weeks or months of cleanup before sensitive use. Geolocation may point to the wrong country. Reverse names may still mention an old service. Security vendors may flag the range because of historic incidents. Mail providers may throttle traffic. A low headline price can become expensive once staff time, customer delay and remediation are included. Serious datacentre inventory policy therefore starts with reputation triage, not just acquisition.
Inventory policy also decides who gets the best stock. A provider may reserve clean ranges for public-sector tenants, enterprise SaaS, financial customers, managed security services or mail-sensitive workloads. It may place noisier customers in isolated pools. It may require deposits or higher recurring fees for dedicated public ranges. It may decline address-heavy customers unless they bring their own space. These decisions are an address economy inside the datacentre. They allocate a scarce public input through private pricing and risk rules.
RIPE NCC cannot and should not choose those commercial allocations. Its role is to make the underlying evidence reliable enough that scarcity cost can be visible. If a transfer is recognised predictably, if holder authority is clear, if reverse-DNS delegation can move without avoidable ambiguity, if route-origin evidence can be changed in time for migration, and if abuse contacts remain current, then buyers, lessors, tenants and customers can price the arrangement more honestly. Hidden cost is where private control grows strongest.
Public-service customers turn address continuity into a term of service
Public-service customers change the stakes because downtime and renumbering are not merely commercial inconveniences. A local authority portal, hospital supplier, emergency communications vendor, research network, school platform, port system, transport operator, utility contractor or government integrator may rely on hosted infrastructure that must remain reachable under stress. The service may sit in an ordinary colocation hall, but its continuity expectations are not ordinary. Public-address evidence becomes part of the service promise.
These customers often ask simple questions in formal language. Which public addresses will the service use? Who controls them? Are they stable through the contract term? How are incidents reported? Can the provider support a recovery site? What happens if the datacentre changes carriers? Can the service be moved without every downstream agency updating firewalls? Are reverse DNS and abuse contacts maintained? Does route-origin evidence support the intended design? These questions sound administrative. They decide whether a provider is acceptable.
Public procurement can unintentionally amplify dependence. A tender may value a hosted service, a sovereign location, a local support team or a resilience claim without specifying address portability. The winning supplier then uses provider-assigned IPv4 because it is fast. The service goes live. Agencies, hospitals, schools or contractors record the endpoints. Years later, exit is difficult because the public identity belongs to the hosting chain rather than the service. The original procurement saved time by avoiding address complexity and paid for it in reduced choice.
The continuity problem is especially sharp for smaller jurisdictions and edge markets within the RIPE NCC region. A small national hoster may support public websites, health suppliers, education systems and local businesses from modest facilities. Its address inventory may be narrow. Its access to transfer markets may be weaker than that of a large European campus. Its customers may lack the staff to manage their own number resources. In such markets, a clean, portable, well-documented address range can have more public value than its size suggests.
NAT pressure can conflict with continuity. A provider under IPv4 scarcity may want to push more tenants behind shared egress. For simple services, that is often acceptable. For public-service customers, shared egress can weaken audit clarity and incident response. If many services appear from the same public address, a complaint, blacklist event or security control can affect unrelated services. The provider may maintain internal logs, but the outside world sees a narrower surface. Public-service customers often need more visible separation.
Exit and swing capacity are part of continuity. A public service cannot always move by switching off one range and turning on another. It may need overlap while agencies update firewalls, while supplier systems test new endpoints, while DNS changes propagate, while help desks brief users and while security teams compare logs. The datacentre or hoster must have enough spare public-address capacity to support the transition. A provider with no swing stock may lock customers in without intending to.
RIPE NCC's public ledger supports these customers indirectly. It gives service providers and tenants a way to show stewardship, contactability, reverse-DNS control and route-origin intent. It does not tell a government how to procure hosting. It does not guarantee resilience. But when the record is accurate and portable, procurement teams can ask better questions: does the supplier control the address evidence, can it move, can it be separated, and what happens if the hosting contract changes? Scarcity then becomes a disclosed operational risk rather than an invisible restraint.
Small operators and hyperscale campuses do not face the same address economy
Datacentre address demand is often discussed as if all providers face the same scarcity. They do not. A hyperscale campus, a large carrier-neutral facility, a national colocation firm, a regional hoster, a managed-service provider and an edge rack operator inhabit different address economies. They share the same exhausted IPv4 world, but they differ in financing, inventory access, engineering depth, customer mix and bargaining power.
Hyperscale and very large campuses can spread address work across many customers and teams. They may have older holdings, broker relationships, strong transfer-market access, internal tooling for reputation management, mature RPKI practices, carrier influence and security staff. They can justify holding spare stock because the revenue base is large. They can also nudge customers toward architectures that conserve public IPv4. Their scarcity problem is real, but it is cushioned by scale.
Large colocation hubs occupy a middle position. They may not be cloud platforms, yet they sit near exchanges, carriers, content networks, security providers and enterprise customers. Their address policy can influence which tenants grow. A hub with clean inventory and predictable evidence can attract managed hosters, bare-metal platforms and regulated customers. A hub that treats address stock as an afterthought may still sell power and space, but higher-value tenants will see friction during onboarding. In dense markets, address readiness becomes a product differentiator.
Small operators face the harshest economics. They may need only modest address stock, but the cost per staff hour and per address can be high. A small hoster serving a national market may lack the capital to buy enough IPv4 for future growth. Leasing may be attractive, but lease evidence may be weak for serious customers. Transfers may be possible, but due diligence and record cleanup can consume scarce staff time. Abuse handling and reverse-DNS service may depend on a few people. A single polluted range can damage a large share of the customer base.
Edge facilities add a separate challenge. They often exist to bring services closer to customers, public networks, industrial sites, media users or local enterprises. Their value is location and proximity, not enormous scale. Yet public IPv4 is less local than power or fibre. A provider may have a promising edge site but lack the address stock to support tenant separation or recovery use. A national or regional customer may want local hosting precisely to avoid distant dependence, only to discover that public-address inventory still comes through a fragile external arrangement.
The RIPE NCC region's variety magnifies these differences. Western European hubs have deep ecosystems and transfer-market expertise. Some Middle Eastern and Central Asian markets have fast digital growth, sovereign-hosting ambitions and fewer mature paths for small providers to acquire clean stock. Some countries have strong public-sector demand but limited local address liquidity. Some operators serve cross-border customers who expect European-style evidence even when local supply is thin. A single institutional rule can land differently across these markets.
Small operators are not automatically more virtuous, and large campuses are not automatically suspect. The institutional point is about bargaining power. Scarcity lets firms with inventory turn public-address readiness into a competitive edge. That can reward planning and good stewardship. It can also entrench older holders and larger platforms if evidence is hard to move. A registry ledger that is accurate, predictable and non-discretionary helps smaller operators most because it reduces the private negotiation burden they cannot easily absorb.
AI and high-density compute should be placed in this context. Dense GPU halls can consume enormous power and space, but they do not make IPv4 demand scale one-for-one with accelerators. A training cluster may expose only a few public services. The address demand comes from management planes, customer portals, API entry points, monitoring, appliance edges, remote access, tenant isolation and proof that customers can reach and audit the service. For large campuses, these needs can be absorbed into mature tooling. For smaller AI infrastructure providers, a shortage of clean public endpoints can delay sales even when the hardware is installed.
The comparative lesson from weaker registry environments is cautionary. Where registry confidence is poor, physical hosting investment can fail to become full revenue because tenants, carriers and customers cannot easily trust address evidence. The RIPE NCC region is not in that position. Its ledger and community institutions are materially stronger. But the lesson remains: datacentre capital is incomplete if public identity cannot be verified. The better the registry evidence, the less private scarcity can dominate the activation queue.
RIPE NCC should strengthen the ledger without planning the halls
The constructive test for RIPE NCC is not whether it can allocate datacentre growth. It should not become a planner of halls, a judge of hosting business models, a discretionary approver of tenant demand or a shadow industrial ministry for IPv4. That would turn scarcity into public bureaucracy. The better role is narrower and more durable: keep the ledger accurate, predictable and portable so that private scarcity cannot too easily become private control.
Accuracy is the first requirement. Holder records, contacts, organisation data, reverse-DNS arrangements and resource status should be clean enough that tenants and counterparties can understand who has recognised authority. Accuracy does not mean exposing every downstream customer. It means the responsibility chain should not depend on guesswork. A datacentre using provider-held, tenant-held, leased or transferred space should be able to explain that status without creating a bespoke trust ceremony for every buyer.
Predictable transfer recognition is the second requirement. Transfers are a supply path for datacentre growth, but they are valuable only when timing and evidence are manageable. Providers and tenants need to know what proof is required, how authority is checked, how reverse-DNS and route-origin readiness can be coordinated, and how legacy or older holdings can be brought into current records without discretionary surprises. Predictability lowers the working-capital penalty attached to address stock.
Evidence portability is the third requirement. A tenant that maintains good records should be able to use the same public evidence across datacentres, carriers, DDoS providers, enterprise customers and cloud-adjacent services. That does not require every private provider to accept every range. It does require the registry evidence to be legible enough that rejection or delay is based on real risk rather than ambiguity. Portable evidence is the institutional answer to private gatekeeping.
Reverse-DNS continuity deserves special attention. It is often treated as a small operational task, but it matters in mail, security, public-sector assurance and customer migration. The responsible party should be clear. Handover timing should be predictable. Delegation paths should not be trapped in stale arrangements. A customer that has paid for dedicated public identity should not discover during a cutover that reverse DNS depends on an absent lessor or retired contact.
RPKI and ROA timing require similar discipline. Route-origin evidence must match the activation calendar. If a tenant changes origin, uses a DDoS provider, moves between halls or shifts from provider announcement to its own ASN, the evidence has to be ready before the service is exposed. RIPE NCC cannot control every route filter or private policy, but it can support clear, reliable processes that make authorisation less ambiguous. In datacentre economics, a late ROA is not a paperwork delay; it can be delayed revenue.
Abuse contactability is also part of address value. Public addresses used in hosting attract complaints. Some are valid, some mistaken, some automated, some malicious. A provider that can receive and route complaints preserves reputation for everyone in the pool. A provider with stale contacts devalues its own inventory and burdens neighbours. RIPE NCC's role is not to police every complaint. It is to preserve enough contact discipline that reputation systems and customers can tell the difference between accountable hosting and abandoned records.
Leasing evidence needs a careful middle path. Overly intrusive registration can chill legitimate flexibility. Too little evidence lets leased scarcity masquerade as durable control. The useful standard is not to expose private commercial terms, but to make authority, delegation, route-origin permission and termination risk clear enough for serious tenants to price. A public-service buyer does not need to see the lessor's margin. It does need to know whether the public identity behind a service can survive the contract term.
Tenant-use evidence should also be clearer without becoming a demand-approval regime. Datacentre providers need a way to distinguish provider infrastructure, customer-dedicated use, temporary migration use, leased use and tenant-held space in records and customer files. The purpose is not to ask RIPE NCC to decide whether a tenant deserves addresses. The purpose is to reduce confusion when a bank, ministry, DDoS provider, upstream or enterprise buyer asks who can make changes and who will answer if traffic causes harm. Service-specific status labels, if carefully limited, can lower verification cost while leaving commercial terms private.
Legacy and older holdings need accepted equivalent proof. A range held through a long corporate history may not fit modern paperwork neatly, yet it may be cleaner and more durable than a newly leased pool. If a datacentre operator or tenant can show continuity, authority, contact control and routing intent through reliable evidence, that proof should be usable without forcing unnecessary discretion. The point is to bring older but legitimate supply into current service, not to punish history for failing to resemble a new allocation file.
Delay metrics would make the hidden bottleneck visible. If reverse-DNS handovers, account-authority updates, transfer recognition, route-origin changes or contact repairs routinely miss migration windows, the address economy will express that failure as stalled racks, postponed customer launches and leased stopgaps. Aggregate reporting need not expose sensitive transactions. It can show whether registry-dependent changes that matter to datacentres are becoming more predictable or more expensive in time. In a scarce environment, time is a price.
Continuity should be the guiding principle across all of these details. A tenant should know whether an address plan can survive a carrier change, a DDoS-provider change, a move between halls, a lessor failure, a corporate restructuring or a customer audit. A provider should know which evidence must be ready before it sells a rack as serviceable capacity. A customer should know whether a public endpoint is stable enough for a contract term. The ledger cannot guarantee every outcome, but it can make continuity testable before dependence forms.
The same applies to NAT and conservation. RIPE NCC should encourage efficient use and IPv6 deployment without treating every request for public IPv4 as waste. Datacentres have legitimate needs for tenant separation, dedicated appliances, customer endpoints, abuse isolation, mail reputation and swing capacity. Conservation rhetoric becomes harmful when it ignores the operating value of public identity. The better stance is evidence-based: ask whether the address plan supports accountability, portability and efficient use, not whether all public IPv4 demand is morally suspect.
Institutional legitimacy depends on non-discretion. Scarcity invites power. If registry procedures appear unpredictable, political or overly moralised, private actors with address inventory will benefit because customers will avoid the public process and accept provider-controlled alternatives. If procedures are thin, neutral and reliable, the ledger remains a tool for many parties rather than a gate held by a few. That is the difference between public coordination and capital control.
The test can be made practical. Are datacentre-relevant registry changes measured for delay? Are reverse-DNS handovers predictable enough for migration windows? Are route-origin updates easy to align with activation? Are holder records current enough for due diligence? Are older holdings recoverable into clean authority without arbitrary friction? Can small operators understand leasing and transfer evidence without hiring a large advisory team? Can public-service customers ask whether a hosted service has portable address evidence? These questions do not plan datacentre growth. They make the scarce input harder to hide.
RIPE NCC's strongest contribution to datacentre address demand is therefore restraint with precision. It should not pretend to know how many racks should exist in Frankfurt, Amsterdam, London, Dubai, Warsaw, Madrid, Istanbul, Stockholm or Almaty. It should not decide whether bare metal, SaaS, colocation, edge hosting or public-sector recovery is the superior use of IPv4. It should maintain a ledger that lets those markets reveal their own costs. When the ledger is accurate, address scarcity is still expensive, but it is visible. When it is portable, tenants can move. When it is predictable, small operators can plan. When it is non-discretionary, public trust does not become private gatekeeping.
The datacentre sales queue will not disappear. Power will still be scarce. Fibre will still matter. Cross-connects will still take time. IPv6 will keep advancing, and NAT will remain a conservation tool. But in the next cycle of hosting growth, many racks will wait on public-address inventory and the evidence that makes it acceptable. RIPE NCC's task is not to fill those racks. It is to ensure that the public record behind them remains good enough that scarce IPv4 does not become a quiet tax on activation, continuity and exit.