Summary
- Hyperscalers perform registry-like functions inside their platforms: they maintain address pools, allocate and reclaim addresses, set eligibility and prices, prevent overlap, expose inventories, and decide where an address may be attached. Their authority is contractual and technical rather than public registration authority.
- Provider-issued external addresses give customers practical use but ordinarily no general right to transfer the same address to another cloud. Internal addresses are even more dependent on platform topology, permissions and product behavior. The result is operational control without public portability.
- Address reputation makes the dependency deeper. Allowlist history, abuse complaints, payment-risk decisions, mail deliverability and partner access can accumulate around an address, while customers often receive limited evidence about prior use, reassignment risk or the consequences of losing it.
- Bring-your-own-address services preserve a separate registry relationship, but they are a bridge rather than a universal cure. Minimum prefix sizes, routing authorization, regional limits, supported-service restrictions, onboarding time and project boundaries can exclude smaller customers or constrain movement.
- Public cloud documentation provides strong evidence of provider control, including internal pool allocation, public-address charging, reservation rules and product-specific mobility. It provides much less comparable evidence about allocation fairness, reassignment history, adverse-action review, reputation repair and exit outcomes.
- NRS should define a cloud address-use record that distinguishes provider-held and customer-held resources, records allocation history and constraints, supports abuse correction, and gives customers exportable evidence without misrepresenting a service entitlement as ownership.
- By the 2027 observation point, the decisive measures should be address portability by class, reassignment delay, reputation disputes, adverse-action restoration time, concentration of public egress, customer-held address adoption and whether smaller users can obtain continuity without acquiring a large transferable block.
The registry comparison should begin with functions, not labels
A regional Internet registry and a cloud provider occupy different institutional positions. The regional registry recognizes resource holdings under community-developed policy, maintains public registration and delegation records, and operates within a framework that expects continuity beyond a single hosting contract. A cloud provider receives or acquires address space, advertises it through its network, and subdivides practical use among accounts and services. Calling both institutions registries without qualification would blur a critical distinction.
The useful comparison is functional. Both maintain pools. Both decide whether a requester is eligible. Both create records linking an address range to an accountable party, although one record may be public and the other private. Both can reclaim unused capacity, investigate abuse, impose conditions, and influence the speed at which a user can deploy. Both must prevent conflicting assignments and maintain accurate operational state. Both increasingly expose address-management tools to customers.
The difference lies in the rights produced. Regional registration is not absolute property, but it usually gives the recognized holder an institutional relationship that is distinct from any one data center or application. A provider allocation is normally inseparable from the provider service. Even a reserved public address can be bound to a region, account, subscription, project, load balancer or other platform construct. Ending the service can end the allocation without transferring the address to the customer.
This makes the cloud layer de facto rather than de jure. It governs what can be done in practice while leaving the formal resource chain unchanged. Public registration may show the hyperscaler as the responsible network. The customer who actually runs the workload appears only in provider records, reverse naming, certificates, application content, commercial databases or incident correspondence. For many observers, the platform is the visible address holder and the customer is a temporary user.
That arrangement is not inherently defective. Shared infrastructure requires internal delegation, and publishing every short-lived virtual assignment would overwhelm public records while exposing unnecessary customer detail. The concern arises when temporary service control carries durable economic consequences without corresponding evidence or remedies. An address can be temporary in contract and still become essential to a customer's partners, security controls and reputation.
Governance should therefore ask five functional questions. Who allocates the address? Who can revoke or move it? What evidence links its use to a customer at a given time? Which operational value survives reassignment or exit? What review exists when the provider's decision is wrong? Those questions reveal the new gatekeeping layer more precisely than a debate over whether a hyperscaler deserves a particular institutional title.
Between 2015 and 2027, address management became a cloud product
In the middle of the 2010s, customers already configured virtual networks and reserved public addresses, but address administration was often treated as one setting among many. As cloud estates expanded across accounts, regions and business units, collision avoidance and inventory became governance problems. Providers responded with increasingly explicit address-management products, organization-wide pools, allocation rules, utilization views and automated attachment to services.
Amazon VPC IP Address Manager describes centralized planning, tracking and monitoring for cloud workloads and permits allocation according to business rules. Its public IPv4 policy features can direct eligible services to selected pools across accounts and regions. Microsoft Azure Virtual Network Manager IP address management creates pools, delegates permissions, allocates non-overlapping address ranges and monitors use. Google Cloud distinguishes internal and external addresses, static and ephemeral use, regional and global scope, provider-issued and customer-brought ranges.
The product vocabulary differs, but each provider has turned allocation into a controlled platform capability.
This shift matters because an address pool now participates in cloud identity and policy. An administrator can grant a team permission to draw from one pool but not another. Organization structure can determine which account receives scarce external addresses. Automated service creation can allocate an address without a separate network team. Quotas, regional availability and product compatibility can reject an otherwise valid design. The platform's access-control system becomes part of number administration.
Scarcity made the layer more visible. AWS announced that from February 2024 it would charge for public IPv4 addresses in use as well as idle addresses, citing rising acquisition costs and encouraging conservation and IPv6 adoption. Google Cloud also increased the listed price for external IPv4 addresses in use by standard virtual machines from the same date. These charges transformed an address from a background attribute into a metered cloud input visible in cost reports.
Pricing can improve utilization. Customers that once assigned an external address to every machine may consolidate egress, use load balancers or adopt IPv6. Yet pricing also confirms gatekeeping power. The provider determines the unit, exemptions, service categories and treatment of customer-brought space. A customer cannot usually respond to a price change by carrying a provider-issued address to another network. Its choices are redesign, payment, release or acquisition of independently recognized resources.
The 2027 endpoint in this analysis is an observation horizon. It is not a prediction that one uniform model will exist. The question to measure through that date is whether cloud address administration becomes more registry-like in accountability as it becomes more registry-like in scale. Better dashboards and finer prices are not enough if allocation history, portability and redress remain opaque.
Internal address space creates a powerful but easily misunderstood domain
Most cloud addresses are not globally routed public resources. Virtual networks commonly use private IPv4 ranges described by RFC 1918, IPv6 space assigned within the customer's design, or other ranges whose meaning is bounded by a virtual network and its connections. Google Cloud documentation, for example, states that internal addresses are local to a virtual network and connected environments rather than publicly reachable. AWS similarly describes private IPv4 addresses as usable for communication inside a virtual network and mapped through translation when public access is needed.
It would be a category error to treat each internal address as a transferable Internet number resource. The same private range can be used by unrelated customers because their virtual networks are isolated. The platform does not confer public uniqueness. A customer that reserves an internal range receives coordination inside a defined domain, not a claim against every other network.
Nevertheless, the internal allocation can be highly consequential. Enterprises connect many virtual networks to offices, factories, acquired companies, suppliers and other clouds. Reusing a private range that already exists elsewhere can prevent direct routing, require translation, complicate security analysis and make a merger expensive. The platform's pool rules and the customer's early choices can shape years of architecture.
The gatekeeping effect appears when platform abstractions define which ranges can be created, enlarged, peered, delegated or advertised. A customer may possess a coherent internal plan but encounter product rules that require a new subnet size, prohibit overlap, bind allocation to a region or restrict movement between projects. Automated address management can prevent mistakes, yet it can also turn one provider's organizational model into the customer's network constitution.
This is especially important for small customers. A global enterprise can maintain independent inventory and negotiate exceptions. A smaller organization may let the provider generate defaults. The default virtual network then becomes the effective address plan. When the organization later adds a second region, a partner connection or another cloud, it discovers that an easy first allocation created a hard boundary.
NRS should avoid asking public registries to register private virtual assignments. It should instead encourage interoperable evidence about scope. An exported record should state the internal range, virtual domain, allocation date, responsible customer unit, overlap constraints, connectivity dependencies and release state. Such evidence helps migration and dispute analysis without pretending that the range is globally exclusive.
The governing principle is domain clarity. A private address has meaning only within a routing and administrative context. Providers should make that context exportable and customers should preserve it independently. A platform can legitimately control allocation inside its infrastructure; it should not make the history of that allocation unknowable when the customer leaves.
Provider-issued public addresses create reputational tenancy
Public cloud addresses are different because outside networks observe them. A static address may anchor a payment endpoint, remote-access rule, mail service, application interface or partner allowlist. An ephemeral address may appear briefly but still generate security events, rate limits and fraud signals. Cloud providers decide how these addresses are reserved, attached, released and reused.
The customer gains use, but the use resembles tenancy. The address is stable only within stated conditions. It may remain reserved while a resource stops, or it may disappear when the resource is deleted. Some platform-managed services allocate addresses that customers cannot directly choose. Global load-balancing products may use anycast addresses with different mobility from a regional virtual-machine address. A customer saying "our address" can therefore refer to several legally and technically distinct arrangements.
Reputation makes those distinctions costly. External services may associate an address with abuse, trustworthy traffic, location, account age or commercial behavior. A newly allocated address can arrive with prior history from another tenant. A long-held address can accumulate positive allowlist status that the customer loses on release. The provider owns the larger pool and controls reassignment, while third parties make independent judgments that neither provider nor customer fully controls.
This creates three evidence gaps. First, customers rarely receive a complete prior-use history when an address is assigned. Privacy and security make full disclosure difficult, but the absence of any standardized cleanliness signal shifts investigation cost to the new user. Second, the provider may receive abuse reports at the aggregate network level and decide whether to forward, suppress or act on them. Third, after reassignment, the former user may need to prove that later activity was not theirs.
Time-bounded allocation evidence would reduce these risks. A provider could issue a signed or otherwise verifiable statement that an address was assigned to a specified customer account during a defined interval, subject to appropriate privacy controls. The statement would not disclose application content or create ownership. It would help incident responders, courts, counterparties and reputation services distinguish users over time.
Reassignment policy also deserves measurement. Providers can publish aggregate quarantine intervals, the share of allocations that receive immediate abuse complaints, restoration time after a false positive and the process for challenging reputation problems. A fixed interval will not clean every address, because external lists update at different speeds. Transparent evidence would at least reveal whether rapid reuse is externalizing costs onto customers.
The term reputational tenancy captures the asymmetry. The customer bears the business effects of the address's reputation while lacking full control over its past or future. Good cloud governance should give the tenant evidence and correction channels even when the underlying address remains provider-held.
Bring-your-own-address service is a bridge, not a universal answer
Customer-brought address services alter the rights structure. AWS documentation states that customers can bring public IPv4 or IPv6 ranges into the platform and continue to own the range while AWS advertises it. Azure describes a custom prefix as customer-owned, requires registration with a routing registry, and treats Microsoft as authorized to advertise the range. Google Cloud creates platform resources representing a customer prefix and delegates portions to projects and scopes.
These services preserve a relationship outside the cloud account. The customer can establish that the range is recognized through the relevant number-resource system, authorize a provider to originate it, and later withdraw that authorization. Reputation and allowlists can remain attached to the customer's range across infrastructure changes. This is much closer to genuine portability than moving a provider-issued address between two services inside one cloud.
The bridge has load limits. Providers impose minimum and maximum prefix sizes, validation steps, route authorization, provisioning periods and product compatibility rules. Google documentation warns that provisioning may take multiple weeks and lists services that do not support customer-brought addresses. Azure distinguishes regional and global models and notes restrictions on movement of derived public prefixes between subscriptions. Cloud-specific resources remain necessary even when the underlying range is independently recognized.
Small customers may be unable to acquire an eligible block, justify the administration, or advertise it outside a provider. IPv4 scarcity raises the entry price. A startup that needs three stable addresses cannot necessarily obtain a portable range of the required size. IPv6 offers more space, but application dependencies, counterparties and provider product support can still make public IPv4 necessary. Treating customer-brought space as the only route to continuity would reserve meaningful rights for larger organizations.
The service also does not eliminate provider control during use. The hyperscaler validates the range, provisions it into internal systems, decides which services support it and controls advertising through its network. A suspended account may lose the ability to attach addresses even if the customer remains the recognized holder. A dispute can therefore interrupt practical use without extinguishing the external resource relationship.
NRS should support customer-brought address services while resisting exaggerated claims. The right should include clear onboarding criteria, timely provisioning, exportable state, documented withdrawal, route-security coordination, no retaliation for exit and tested restoration. It should also be possible to distinguish a provider's technical refusal from a challenge to the customer's underlying resource status.
For smaller users, an intermediate model may be needed: portable service endpoints, stable provider-neutral egress through qualified intermediaries, or multi-provider services that preserve identity without assigning a large independent IPv4 block. These models must be evaluated carefully for new concentration. The objective is continuity proportional to need, not universal acquisition of scarce addresses.
The real control surface extends far beyond an address console
Cloud address authority is distributed across account identity, organization policy, billing, quotas, network products, abuse controls and route operations. A customer can possess permission to view an address but lack permission to attach it. A project can hold a reservation while an organization policy prevents the target service. A valid customer-brought range can remain unusable until routing validation and provisioning complete. An unpaid invoice can suspend the account that contains every network control.
This means that an address inventory alone does not reveal effective control. Review must trace who can create a pool, delegate from it, reserve a specific address, move it between resources, change advertisement, release it and restore it after error. Each action may use a different role. Some are available through a public interface; others require provider support or internal action.
Automation adds speed and opacity. Infrastructure tools can create and destroy addresses as part of larger deployments. Managed services can allocate public endpoints without the customer explicitly requesting a particular address. Auto-scaling can multiply internal assignments. These capabilities are useful, but they make historical evidence essential. A present-state console cannot answer who used an address three months earlier or why it changed.
Billing is a governance lever because address charges can be account-specific and immediate. A cost-control team may release idle addresses without understanding their external reputation value. A provider can alter pricing categories across a large installed base. Contracted discounts may protect one customer but not another. The resulting decisions reshape address use even though no registry policy changed.
Abuse response is another lever. Providers must act against harmful activity, compromised systems and repeated violations. They may limit traffic, quarantine an address, suspend a resource or close an account. The legitimacy question is not whether action is permitted, but whether evidence is specific, notice is safe, correction is possible and unrelated resources are protected where feasible.
Routing remains the deepest lever. For provider-held space, the hyperscaler normally determines how the aggregate and more-specific routes are announced. Customers can configure platform endpoints but do not control the full external routing decision. For customer-brought space, authorization is shared: the holder can make route-security statements or other approvals, while the provider implements advertisement through its network. Incident analysis must separate those roles.
A robust cloud address-use record should therefore combine state from several control domains. It should record resource class, source pool, account scope, attachment, allocation interval, routing status, billing class, responsible roles, relevant adverse actions and portability constraints. Export should be possible without exposing secret credentials or other tenants. That record would make the gatekeeping layer inspectable.
Platform documentation proves control but not institutional fairness
Official cloud documentation is unusually valuable evidence because it describes the actions customers can actually perform. AWS documents private and public address behavior, IP address management pools, organization-wide policies, public-address insights, customer-brought ranges and public IPv4 charges. Azure documents centralized internal pools, role requirements, custom prefixes, customer ownership of brought ranges and restrictions on derived resources. Google documents internal scope, external address classes, reservation behavior, customer-brought prefix hierarchy, project limits and pricing.
Taken together, these sources establish several facts with high confidence. Providers actively allocate addresses rather than merely transporting customer traffic. They distinguish provider-issued and customer-brought space. They bind address use to platform constructs. They charge for some forms of scarcity. They make portability conditional on product design. They expose enough inventory to support internal governance.
The documentation does not establish that allocation is fair across customers. It rarely shows the distribution of clean versus troubled addresses, the number of customers denied a requested class, the frequency of mistaken releases, the concentration of public egress behind managed services, or the result of address-related appeals. Product documentation explains intended behavior; it does not measure institutional outcomes.
Customer and network data are therefore the necessary second layer of evidence. Billing records can show how address charges change architecture. Address inventories can show holding time and utilization. Flow summaries can show concentration behind shared egress, provided privacy is protected. Abuse-ticket histories can show complaint rates and correction time. Migration records can reveal how often endpoint identity blocks exit.
No single customer dataset can represent an entire hyperscaler. Large enterprises are more likely to have sophisticated inventory, negotiated support and customer-brought space. Small users may rely on defaults and lose addresses without preserving records. Research should stratify by customer size, service type, region, address class and support tier rather than publish one global average.
Provider-supplied aggregate data should be independently defined. If one cloud counts an address as portable when it can move within a region and another counts only movement across accounts, comparison is meaningless. NRS can define measures before collecting them: movement within a service, movement within a provider, movement to another provider, and continuity through customer-held space are four different outcomes.
Evidence should also record absence. If providers cannot state how often reassigned addresses inherit reputation problems, that uncertainty is itself relevant. A mature institution does not need perfect data before acting, but it should identify which consequences it does not yet measure.
A functional test can identify when platform power becomes registry-like
Not every hosting provider with a small address pool constitutes a new governance layer. Scale matters, but scale alone is limited public evidence. A functional test should examine whether the provider's decisions materially shape access to addresses, continuity of digital services and the evidence available to outsiders.
The first criterion is allocation authority. Does the provider decide which account or service obtains an address from a large shared pool? The second is persistence control. Can it determine whether the address survives a restart, resource replacement, project move or contract change? The third is external consequence. Do other networks rely on the address for routing, reputation, authentication or enforcement?
The fourth criterion is information asymmetry. Does the provider possess historical allocation and abuse data that the customer and public registration system lack? The fifth is rule-setting. Can it change prices, quotas, eligibility or supported uses across many customers? The sixth is remedy. Can it restore an address or correct an attribution after a dispute, and is there any independent route if it refuses?
A provider that satisfies most of these criteria exercises registry-like power even if it rejects the name. The conclusion does not grant it public authority. It triggers expectations proportional to the power: accurate records, transparent classes, careful reassignment, bounded adverse action, evidence export and review.
The test also applies to managed hosting resellers and platform intermediaries. A reseller may receive one cloud account and divide addresses among hundreds of customers. From the end user's perspective, the reseller is the immediate allocator and source of evidence. Yet the reseller itself depends on the hyperscaler. Governance must trace the full delegation chain rather than assume the largest brand is the only gatekeeper.
Shared egress services complicate attribution. Hundreds or thousands of customers may appear behind one public address, with differentiation by port, time or higher-layer identity. The platform may control the translation state while the customer controls application logs. Neither side alone can always answer an incident request. Registry-like responsibility in this setting means maintaining a reliable division of evidence, not publishing every private mapping.
The functional approach prevents institutional inflation. It does not call every allocator a regional registry. It recognizes that address governance now occurs in layers and that rights can weaken at each delegation. The appropriate response is a chain of accountable custody and use, with each institution responsible for the decisions it actually makes.
Reputation governance requires correction without promising innocence
An address reputation score is not a public title. It is a judgment made by a mail operator, fraud service, threat-intelligence company, partner or other network based on its own observations. Cloud providers cannot guarantee that every external party will trust an address. Customers also cannot demand deletion of accurate abuse history merely because they received the address later.
What governance can require is accurate temporal attribution. If harmful traffic occurred before the current allocation, the new customer should be able to present credible evidence of the change. Reputation services should be encouraged to use allocation intervals and fresh behavior rather than assume one continuous user. Providers should supply a bounded verification channel that confirms tenure without revealing unnecessary account data.
Providers must also distinguish address reputation from account risk. A customer may have excellent history but receive a recycled address with poor external standing. Conversely, a clean address does not excuse a compromised account. Support teams should investigate both dimensions instead of treating an external blocklist as conclusive proof against the current customer.
Correction procedures should state required evidence, expected response time and appeal. An address assigned to a critical public service may justify faster review than a speculative reservation, but basic access should not depend entirely on premium support. Aggregated statistics should show how many reputation cases were resolved, how many involved prior tenants and how long service impact lasted.
Quarantine can help but must be tested. Holding a released address for a period may allow caches and lists to update, yet the appropriate duration varies. Some reputation signals decay quickly; others persist until a manual request. Providers should combine time with active checks and disclose the limits. A claim that every recycled address is clean would be less credible than measured residual risk.
Customer-held ranges shift some responsibility. The holder carries reputation across providers and cannot blame reassignment for its own history. This persistence is a benefit for trustworthy users and a discipline for poor ones. NRS should make that distinction clear when advocating portability: continuity preserves both positive and negative evidence.
The objective is not a right to a favorable score. It is a right to know what tenure can be proven, challenge mistaken attribution and avoid inheriting undisclosed operational harm without recourse. That is a modest but important counterpart to provider allocation power.
Exit reveals the difference between convenience and a durable right
Cloud services often make entry easier than exit. A customer can reserve an address in seconds, attach it to a service and distribute it to partners. Years later, the address may appear in hundreds of firewall rules, certificates, contracts and monitoring systems. The provider-issued address still cannot leave the platform, so migration requires coordinated change by every dependent party.
This is not always a provider-created trap. Customers choose hard-coded allowlists, neglect names, postpone IPv6 and fail to maintain endpoint inventories. Some external systems genuinely require stable addresses. Governance should allocate responsibility honestly: customers must design for change, while providers must describe mobility constraints before dependency accumulates.
Exit evidence should include a complete address inventory, attachment history, address class, customer-brought status, routing configuration, relevant reverse naming, release schedule and known managed-service dependencies. It should distinguish records the customer can preserve from state that will be deleted. A machine-readable export is more useful than screenshots from several consoles.
Provider-issued addresses require a transition interval rather than transfer. Customers should be able to retain the old address long enough to operate old and new endpoints in parallel, subject to payment and security. Sudden reclamation at account closure can turn an ordinary commercial move into an outage. Where abuse or insolvency makes continuation risky, a neutral continuity service or narrowly scoped exception may be appropriate.
Customer-brought ranges require a different exit test. The provider should stop advertising at an agreed time, release internal references, support route-security changes and avoid claiming residual authority. The incoming network should be able to advertise after safe coordination. Monitoring must detect overlap or a gap. The customer should receive confirmation that the old platform cannot reactivate the route unilaterally.
Names and application-layer identity reduce dependence but do not remove it. DNS changes take time, counterparties may pin addresses, and some security systems treat new origins as risk. Exit planning must therefore map technical and institutional dependencies. A provider can support good design through documentation and tools; it should not describe address loss as trivial merely because a name exists.
A meaningful portability metric counts successful service transitions, not only address moves. For provider-held space, success means preserving reachability and evidence while changing the endpoint. For customer-held space, it means moving the address authority itself. Reporting both prevents an inflated claim that every customer has the same form of freedom.
Adverse action should be specific, time-bounded and reviewable
Cloud providers face real abuse at scale: botnets, fraud, attacks, malicious hosting, credential theft and sanctions exposure. They need authority to act quickly. Address governance fails, however, when action against one workload silently disables unrelated endpoints or when a customer cannot discover whether the problem concerns traffic, identity, payment or an inherited reputation signal.
Specificity should be the default. If one address or service is compromised, the provider should avoid withdrawing an entire customer range unless evidence supports the broader risk. If account credentials are compromised, wider suspension may be necessary, but the reason and restoration path should be distinct from an address-level complaint. Internal records should preserve who authorized the action and what evidence was reviewed.
Notice must reflect security. Advance warning can enable an attacker to destroy evidence or continue harm. Immediate action may therefore be justified. The customer should still receive safe information as soon as possible: affected resources, rule category, required containment and review channel. Vague references to terms are inadequate when a critical endpoint is disabled.
Review should be capable of technical restoration. A customer that proves the current allocation did not generate the reported traffic needs more than an apology. The provider may need to restore attachment, update internal reputation, issue tenure evidence and contact a reporting party. Where the address has already been reassigned, an equivalent clean address plus transition help may be the only practical remedy.
Independent oversight need not inspect every abuse decision. It can review samples, repeated failures, high-impact cases and systemic disparities. Providers can publish aggregate adverse-action rates by cause and resource class. NRS can compare whether smaller customers face longer restoration because they lack premium support, while protecting incident details.
Account closure is the hardest case because address, data, identity and billing rights converge. Essential public services may require continuity even during a dispute. Providers should establish escalation for health, emergency, civic and critical infrastructure workloads without declaring those customers immune from security action. Continuity can mean a controlled move, not indefinite service.
The institutional standard is bounded power. Fast action protects networks; reasoned restoration protects legitimacy. A hyperscaler that can disable practical address use for millions of customers should accept corresponding duties to record, explain and correct its decisions.
Small customers bear the largest gap between use and portability
Large enterprises can bring address space, buy premium support, maintain multi-cloud architecture and negotiate transition terms. Small businesses, civil-society groups, researchers and local public bodies often use provider-issued addresses and default networking. Their need for continuity may be substantial even when their address count is tiny.
Scarcity economics can disadvantage these users twice. They pay recurring public IPv4 charges but cannot convert those payments into a portable interest. Acquiring an independent IPv4 range may be uneconomic or administratively disproportionate. IPv6 can reduce scarcity dependence, yet external services, users and security partners may still require IPv4 reachability.
NRS should not solve this by promising a transferable address to every virtual machine. It can support pooled continuity services with clear governance. A qualified intermediary could provide stable egress or ingress across multiple clouds, retain time-bounded customer attribution and permit movement among underlying providers. The intermediary must itself offer exit, audit and concentration disclosure or it simply becomes another gatekeeper.
Provider-neutral identity can also reduce address dependence. Mutual authentication, signed service identity, modern name resolution and application-level authorization can replace some allowlists. NRS can publish transition guidance and sponsor compatibility testing. It should remain realistic: regulated partners and legacy equipment will not abandon address rules at once.
Subsidized customer-brought IPv6 and training could give smaller organizations durable address identity where IPv4 is unavailable. Providers should make IPv6 support consistent across managed services and clearly identify gaps. A service that advertises IPv6 at the virtual-network level but omits it from a critical managed product does not offer complete portability.
Support access is part of fairness. An address-attribution error can close a small organization's only public channel. Basic customers need a documented, authenticated appeal that reaches staff able to inspect allocation history. Premium tiers may buy faster general support, but correction of the provider's own address records should not be treated as a luxury feature.
The relevant measure is not equal architecture. It is whether users with small requirements can obtain proportional continuity, reliable evidence and correction. If only holders of large blocks can escape reputational tenancy, cloud address governance will reproduce scarcity privilege beneath an apparently elastic service.
NRS can create a cloud address-use record without inventing ownership
The Number Resource Society's most useful intervention would be a standard record for delegated cloud use. The record should identify the provider-held or customer-held status of the resource, the allocating entity, the customer account or privacy-preserving reference, the allocation interval, address class, scope, attachment category and portability conditions. It should state who can verify the record and how long verification remains available.
For internal space, the record should state that uniqueness is limited to a defined virtual domain. It can include pool lineage, connected environments, overlap checks and release state. For provider-issued public space, it should state that the customer received use rather than a transferable registration. For customer-brought space, it should link the cloud delegation to the independent holder relationship without duplicating the public registry.
The record must be exportable. Customers should be able to preserve allocation history after account closure. Cryptographic verification or another tamper-evident method can make the evidence useful in disputes, but the design should avoid turning a sensitive customer directory into a public lookup. Selective disclosure can confirm a tenure interval to an authorized counterparty.
Providers should expose correction procedures. If the account reference, interval or release state is wrong, the customer can request amendment while preserving the prior version and reason. This resembles responsible ledger practice without treating every operational event as immutable truth. Accuracy includes the ability to correct error transparently.
The record should travel with abuse cases. A complaint can be linked to the address and observed time, then matched against the allocation interval. Providers can route the case to the correct customer without disclosing another tenant. After reassignment, the new user can show that the event predates its tenure. This improves accountability for both customers and complainants.
NRS should develop the record with hyperscalers, smaller hosts, regional registries, security operators, privacy specialists and customer groups. A standard written only by providers may prioritize operational convenience; one written only by registries may overstate public-registration concepts. The value lies in representing the boundary accurately.
Adoption can begin voluntarily through reference exports and independent testing. Procurement by governments and large enterprises can require support. Over time, aggregate reporting can show coverage, correction rates and verification success. The Society should judge the record by whether it resolves real incidents and migrations, not by the number of fields completed.
Three cases show where the new gatekeeping layer matters
Consider a health-service supplier that has used one provider-issued static address for six years. Hospitals allow traffic from that address, and external fraud systems associate it with stable behavior. The supplier decides to change clouds after a price dispute. It can export its application data but cannot take the address. Each hospital must update controls, and one legacy system has a quarterly change window.
The provider has not violated a transfer right because none was granted. Yet the address has become a practical switching cost. Good governance would have disclosed non-portability, supported a paid overlap interval, exported allocation evidence and offered migration guidance. The customer should also have maintained a dependency inventory and tested a named endpoint. Responsibility is shared, but only the provider can preserve the old allocation during transition.
Now consider a small retailer assigned a recycled public address. Payment partners reject connections because the address appears in an external risk database. The retailer cannot see prior use and basic support says the address is technically functioning. Releasing it may produce another unknown address and require partner changes. A cloud address-use record and reputation appeal could confirm recent assignment, permit a clean replacement and help the external service correct temporal attribution.
The provider cannot command the payment partner to change its model. It can prove tenure, inspect whether its own systems knew of prior complaints and measure repeated reassignment harm. If a pool generates unusually high false positives, continued random allocation without warning would externalize a known cost.
The third case involves an enterprise bringing its own range to a hyperscaler. A contract dispute leads to account suspension while the range remains registered to the enterprise. The provider stops allowing attachment but continues route advertisement for several hours. The incoming cloud cannot complete its own activation because overlapping announcements would be unsafe.
This case separates formal holding from platform control. The enterprise retains the resource relationship, but the old provider controls the practical exit sequence. A customer-brought service should have an emergency withdrawal channel, authenticated contacts outside the suspended account, defined cessation times and independent route observation. Commercial claims can continue after safe routing authority moves.
Each case involves a different right. The first needs service continuity without address transfer. The second needs temporal reputation evidence. The third needs withdrawal of delegated routing authority. Calling all three portability would conceal the remedy. Layered governance works only when it names the actual control point.
Institutional legitimacy depends on admitting the hybrid structure
Regional registries may be tempted to say that cloud assignments are ordinary downstream use and therefore outside their concern. Hyperscalers may say that addresses are simply service attributes. Customers may describe a long-held address as if payment created ownership. Each statement contains part of the truth and avoids part of the responsibility.
The regional system remains responsible for the provider-level resource relationship, accurate public data and policy concerning delegation or transfer. It should not attempt to micromanage every virtual assignment. It can nevertheless encourage evidence standards and ask large holders how downstream attribution, abuse handling and customer-brought routes are governed.
Providers remain responsible for the service layer they control. They should not imply that a regional registration answers customer-level attribution when it names only the hyperscaler. Nor should they use the absence of customer ownership to justify opaque reassignment. Contractual status limits transfer; it does not erase duties of accurate administration.
Customers must understand what they receive. Paying for a reserved address does not necessarily buy the address. Building a critical allowlist around a provider-issued endpoint creates exit risk. Customers should ask whether an address is ephemeral, reserved, service-managed or customer-brought and preserve evidence accordingly.
Public authorities should regulate carefully. A rule requiring publication of every cloud address-to-customer mapping could expose sensitive infrastructure and create a high-value surveillance source. A rule assuming the public registration identifies the end user could lead to false attribution. Better policy specifies preservation, lawful access, correction and oversight while minimizing unnecessary disclosure.
NRS can give the hybrid structure a legitimate vocabulary. "Recognized holder," "cloud delegator," "customer user," "routing operator" and "reputation decision-maker" describe distinct roles. Rights and duties can then attach to action rather than branding. The Society's positive contribution is not to displace existing institutions, but to make the delegation chain intelligible.
Legitimacy will be earned through restraint. NRS should not claim jurisdiction over private networks merely because they contain addresses. It should intervene where interoperability, continuity, evidence and resource stewardship cross institutional boundaries. That focus is narrow enough to respect provider operation and broad enough to protect customers from invisible gatekeeping.
The 2027 evidence agenda should measure outcomes rather than product counts
By the end of the observation period, researchers should be able to compare providers on several address-governance outcomes. The first is allocation transparency: can a customer identify pool source, address class, tenure, responsible account and constraints? The second is continuity: how long can a provider-issued endpoint overlap during migration, and how reliably can customer-brought routes move?
The third is reassignment quality. Providers should report quarantine practice, complaints linked to prior tenants, clean-replacement requests and restoration time in aggregate. The fourth is adverse action: which address-level interventions occur, how often broader accounts are affected and how many decisions change after review. The fifth is concentration: what share of customer traffic exits through provider-controlled shared addresses, dedicated provider addresses and customer-held ranges?
Cost measures should separate recurring address charges, translation services, logging, support and migration. A low per-address price can coexist with expensive dependence if moving requires changes across many partners. Conversely, a visible charge may encourage efficient use and fund better management. Evidence should connect price to behavior rather than presume one moral conclusion.
Portability requires a matrix. Movement of a static address between machines is not movement between regions. Movement between projects is not movement between providers. Moving a customer-held prefix is not the same as preserving service while changing a provider-issued endpoint. Each cell should have measured completion time, failure rate and customer eligibility.
Smaller-user outcomes need separate attention. Researchers should sample organizations without customer-brought ranges or enterprise support. Can they obtain tenure evidence? Can they challenge inherited reputation? Can they keep an old endpoint during an orderly move? If the answer depends on personal escalation or exceptional goodwill, the right is not mature.
Provider documents, customer records and external network observations should be reconciled. Documentation establishes designed capability. Customer data shows use and cost. Route collectors, reputation services and incident records show external effect. Conflicts should be investigated rather than averaged away. An address marked released in one system but still observed externally is precisely the kind of discrepancy governance must expose.
The evidence agenda should remain proportionate. Publishing individual customer mappings or detailed security events is unnecessary. Aggregated measures, controlled audits and customer-verifiable records can reveal institutional performance without creating a public catalogue of vulnerable systems.
Cloud address governance needs rights matched to resource class
A single declaration of address rights would fail because internal, provider-issued public and customer-held public resources differ. Internal allocations need scope clarity, export and collision evidence. Provider-issued public addresses need tenure records, reputation correction, transition time and honest non-portability disclosure. Customer-held ranges need timely onboarding, routing coordination, service compatibility and safe exit.
All classes need accurate administration, secure authorization and review. Customers should know who can allocate, attach, release and restore an address. High-impact actions should produce durable records and independent notice. Provider support should be able to correct its own state without demanding proof that only the provider possesses.
Rights also create duties. Customers must maintain current contacts, secure accounts, avoid harmful use, plan migration and preserve dependency inventories. Holders of brought space must maintain registration and routing authorization. Providers are entitled to reclaim unused provider space under clear terms and protect networks against abuse.
NRS should publish model service language. It can state that a provider-issued address remains provider-controlled, identify persistence conditions, define export, set transition options and explain reassignment. For customer-brought ranges, it can define validation, advertisement, withdrawal, residual records and dispute separation. Standard language would make services comparable without fixing commercial prices.
Independent testing should simulate realistic failures: accidental release, inherited reputation, locked account, organization restructuring, provider move, route overlap and urgent abuse. A service should not receive a strong accountability rating because its ordinary console works. The decisive test is whether evidence and authority survive stress.
The Society should also promote designs that reduce unnecessary IPv4 dependence. IPv6, names, application identity and shared but accountable gateways can all help. None should be presented as instant replacement for stable public addresses. Credibility comes from recognizing transition constraints while changing incentives.
Cloud providers have become de facto address registries in a limited but important sense: they govern allocation and practical use for an enormous share of modern infrastructure. They have not thereby acquired the public legitimacy of regional registries, and their customers have not acquired transferable rights in provider pools. The next layer of governance must hold both truths at once.
The constructive standard is clear. Provider control should come with inspectable records, bounded reassignment, correction, safe adverse action and realistic exit. Customer-held resources should remain portable in practice. Internal allocations should retain domain context. Reputation should follow evidence rather than institutional convenience. These measures would not turn clouds into public registries. They would make private gatekeeping accountable to the operational consequences it already creates.