Why IPv4 Supply Chain Stability Is a Core Infrastructure Requirement

IPv4 is often treated as a simple infrastructure input: an organisation needs public address space, a provider supplies it, and the network begins using it.

In practice, the structure behind that address space can be much more complex.

An IPv4 service may depend on:

• the underlying resource holder;
• a broker or marketplace;
• a leasing provider;
• a reseller;
• registry-facing administration;
• RPKI and IRR processes;
• upstream connectivity;
• reverse DNS;
• abuse handling; and
• long-term renewal arrangements.

None of these relationships is inherently problematic.

The real risk appears when important dependencies are difficult to see, responsibilities are unclear, or one upstream relationship can change without a defined continuity plan for the customer.

For enterprises that depend on stable public IPv4, supply-chain stability is therefore not simply a procurement concern.

It is an infrastructure-continuity requirement.

IPv4 Supply Chain Stability: Quick Answer

IPv4 supply-chain stability means that the commercial, registry-facing and operational relationships supporting an IPv4 service are sufficiently clear and resilient that the customer can continue using the required address capacity when conditions change.

A stable supply chain does not require every function to be controlled by one organisation.

It requires:

• clear contractual responsibility;
• clear registry-facing responsibility;
• defined routing-support processes;
• accurate RPKI and IRR coordination;
• known renewal obligations;
• visible upstream dependencies;
• continuity planning; and
• customer operational independence.

Additional intermediaries can be useful when they provide a clear function.

Risk increases when those additional layers create dependencies without equally clear accountability.

What Is the IPv4 Supply Chain?

The IPv4 supply chain describes the commercial and administrative relationships through which address space reaches the network that ultimately uses it.

A simplified arrangement might look like:

underlying resource relationship → provider or intermediary → customer → running network

More complex structures may involve:

resource holder → broker → marketplace → leasing provider → reseller → customer

Each organisation may perform a legitimate role.

For example:

• a resource holder maintains the upstream relationship associated with the address space;
• a broker identifies supply;
• a marketplace enables matching;
• a leasing provider manages the ongoing service;
• a reseller supports a specific customer segment; and
• the customer operates the addresses within its own network.

Complexity becomes a concern only when the relationships are poorly defined or continuity depends on parties the customer cannot identify or hold accountable.

More Intermediaries Do Not Automatically Mean More Risk

It is easy to assume that each additional intermediary automatically creates another failure point.

That is too simplistic.

A multi-party IPv4 structure can work effectively when each party:

• has a clearly defined function;
• has documented responsibilities;
• can be identified by the customer or provider;
• supports the technical requirements of the service; and
• has a continuity process if its role changes.

A single-provider structure can also fail if responsibilities are unclear or operational processes are weak.

The number of parties matters less than whether every dependency is visible, necessary and accountable.

IPv4 Exists Across Several Different Layers

Supply-chain discussions often become confusing because several different parts of IPv4 infrastructure are treated as though they were the same.

A clearer model separates four layers:

commercial relationship → registry state → routing authorization → operational use

These layers should remain sufficiently aligned, but they are not interchangeable.

A registry record does not announce a BGP route.

A BGP route does not establish every contractual right.

A ROA can authorise an ASN but does not define the complete commercial relationship.

Operational continuity therefore depends on the relationships between these layers, not on control of any one layer alone.

Registry State Is Important, but It Is Not the Entire Supply Chain

Regional Internet Registries perform important coordination functions.

These can include:

• resource registration;
• transfer processing;
• RPKI-related services;
• reverse DNS;
• organisation records; and
• other coordination functions.

These functions help preserve uniqueness and maintain useful administrative information.

But registry state should not be confused with the complete operational reality of the resource.

Registry state describes an important coordination relationship, but it is not identical to commercial rights, routing behaviour or network operation.

Supply-chain resilience therefore requires registry-facing responsibility to be clear without turning registry coordination into operational control of the customer network.

Where IPv4 Supply Chains Can Become Fragile

Several types of dependency can create continuity problems when responsibilities are unclear.

1. Renewal Dependency

The organisation contracting with the customer may not be the same organisation controlling the upstream commercial relationship associated with the supplied address space.

If an upstream agreement ends, the downstream provider may have limited ability to preserve the same prefix.

Customers should understand:

• who controls the upstream relationship;
• how renewal is structured;
• what the provider has contractually committed to;
• what happens if the upstream relationship changes; and
• whether replacement or continuity arrangements exist.

2. RPKI Dependency

A customer may need a valid ROA for its origin ASN.

The relevant question is:

Who can make the required authorisation change, and how quickly can it be executed?

A multi-party structure is not necessarily problematic if this process is known and reliable.

Problems arise when the customer or service provider must pass through several unclear approval layers before legitimate routing changes can be made.

3. IRR Dependency

IRR records may also need to change as the customer deploys, migrates or changes origin ASN.

Customers should know:

• who controls the relevant maintainer;
• who creates the route object;
• who changes the origin ASN;
• how quickly updates occur; and
• who removes stale information when service ends.

4. Reverse DNS Dependency

Reverse DNS can be important for email, infrastructure services and operational administration.

The service structure should clearly identify who controls delegation and how the customer requests changes.

5. Abuse Handling Dependency

IPv4 services need a clear abuse-response process.

When multiple organisations are involved, reports may otherwise move between parties without clear ownership of the response.

The service should define:

• who receives abuse reports;
• who communicates with the customer;
• what remediation is expected;
• what escalation process applies; and
• what circumstances could affect continued service.

6. Reputation Dependency

IPv4 address space can carry operational history from prior use.

Poor reputation can affect:

• email delivery;
• security filtering;
• fraud systems;
• geolocation;
• blocklists; and
• third-party network acceptance.

Supply-chain stability therefore also includes understanding who is responsible for reputation screening, abuse remediation and ongoing monitoring.

Why Routing Control Should Not Be Centralised With the Provider

A stable IPv4 supply chain does not require the provider to control the customer's network.

The customer remains the operator of its own infrastructure.

The customer may control:

• BGP policy;
• traffic engineering;
• network architecture;
• upstream selection;
• applications;
• security policy; and
• deployment decisions.

The provider may support administrative processes that enable legitimate use, including:

• RPKI coordination;
• IRR updates;
• LOA-related processes;
• reverse DNS;
• registry-facing administration; and
• continuity planning.

Upstream service responsibility and downstream network operation should remain clearly separated.

The Real Objective: Continuity, Not Symbolic Ownership

Ownership and direct holding can provide meaningful commercial and administrative control.

They should not be dismissed as merely symbolic.

For some organisations, purchasing IPv4 may be the correct long-term strategy.

But direct holding does not eliminate every dependency surrounding the resource.

A holder may still depend on:

• accurate registry state;
• RPKI;
• IRR;
• reverse DNS;
• routing acceptance;
• corporate records; and
• other coordination processes.

The relevant lesson is therefore not:

ownership is an illusion

but:

ownership alone does not guarantee operational continuity.

Why IPv4 Supply-Chain Stability Becomes More Important Over Time

At the beginning of a deployment, an IPv4 address may appear interchangeable.

Over time, the same address can become embedded in:

• customer allowlists;
• firewall policies;
• APIs;
• banking systems;
• payment infrastructure;
• VPN configurations;
• DNS;
• security systems;
• SaaS integrations;
• partner platforms; and
• compliance documentation.

At that point, changing the address can affect systems outside the organisation's direct control.

Renumbering may require:

• customer communication;
• firewall changes;
• bank approval;
• third-party allowlist updates;
• security reviews;
• DNS changes;
• API changes; and
• scheduled migration work.

Once an IPv4 address becomes part of network identity, supply continuity becomes a business-continuity requirement.

What Makes a First-Party IPv4 Model Different?

A first-party IPv4 model aims to reduce unnecessary organisational distance between the service provider and the upstream resource relationship supporting the service.

Conceptually:

Customer

→ operates the network and uses the IPv4 capacity

First-party provider

→ carries defined upstream commercial and registry-facing responsibilities associated with delivering the service

Registry layer

→ supports uniqueness, registration and related coordination functions

This does not mean the provider controls every layer.

It means responsibility for the service can be easier to identify.

The first-party advantage is clearer accountability, not centralised governance.

Fewer Unnecessary Dependencies Can Improve Continuity

Simplifying a supply chain can improve service delivery when unnecessary organisational boundaries are removed.

But the objective should not be to eliminate every third party.

Some third parties provide useful and specialised capabilities.

A better design principle is:

Keep dependencies that add value, remove dependencies that add complexity without improving service, and make every remaining responsibility clear.

Centralised Compliance Is Not the Same as Resilience

It can be tempting to describe a first-party service as beneficial because compliance, registry administration or lifecycle control is centralised.

Centralisation alone is not a resilience strategy.

A single dependency can itself become a failure point.

A more resilient structure focuses on:

• clear responsibility;
• accurate records;
• auditable processes;
• known failure paths;
• customer operational independence;
• continuity planning; and
• portability where practical.

The objective is not concentrated control.

It is predictable service responsibility.

Continuity Should Not Create Unnecessary Provider Lock-In

IPv4 supply-chain stability should not require the customer's long-term network identity to become permanently tied to one unrelated infrastructure provider.

An organisation may change:

• hosting provider;
• data centre;
• cloud infrastructure;
• upstream transit;
• routing architecture; or
• application platform.

Where technically and contractually possible, these changes should not automatically force the organisation to renumber its network.

Provider-neutral continuity and portability can therefore be important parts of a resilient IPv4 service design.

Direct Holding vs Multi-Party Leasing vs First-Party Service

None of these models is universally superior.

The right structure depends on the customer's capital strategy, technical requirements, internal expertise and continuity needs.

What Enterprises Should Ask About IPv4 Supply-Chain Stability

Before depending on an IPv4 service for production infrastructure, organisations should ask:

• Who is my direct contractual counterparty?
• Who carries the upstream resource relationship?
• Who carries registry-facing responsibility?
• How many contractual layers are involved?
• Who can update RPKI?
• Who can update IRR?
• Who controls reverse DNS?
• Who handles abuse?
• Who monitors address reputation?
• What happens at renewal?
• What happens if an upstream agreement ends?
• What happens if the customer changes infrastructure?
• Can the same prefix remain usable during migration?
• Which responsibilities belong to the customer?
• Which responsibilities belong to the provider?
• Who is accountable for continuity?

These questions expose supply-chain structure much more effectively than comparing lease prices alone.

Why Price Alone Cannot Measure IPv4 Supply-Chain Risk

A low-cost IPv4 service is not automatically unstable.

An expensive service is not automatically resilient.

Two offers with similar pricing may have very different:

• contract structures;
• registry-facing relationships;
• renewal dependencies;
• technical-support processes;
• address reputation;
• portability; and
• continuity obligations.

Price tells you what IPv4 capacity costs. Supply-chain structure tells you what happens when one dependency changes.

Why LARUS Uses a First-Party IPv4 Model

LARUS approaches IPv4 leasing as an ongoing infrastructure service rather than only an address-matching transaction.

The model is designed around several principles.

Clear Upstream Responsibility

Customers should know which organisation is accountable for delivering the IPv4 service.

Customer Operational Independence

Customers retain control over their own routing, network architecture, applications and infrastructure.

Registry-Facing Support

The provider carries defined upstream responsibilities associated with the IPv4 capacity used to deliver the service.

Reduced Unnecessary Dependency

Additional commercial or organisational layers should exist only when they add meaningful capability.

Continuity Planning

Renewal, network migration and upstream change should be considered before they become urgent incidents.

Provider-Neutral Continuity Where Practical

Where an IPv4 address becomes part of long-term network identity, avoidable renumbering and unnecessary infrastructure lock-in should be reduced.

Learn more about LARUS IPv4 Leasing Continuity Assurance .

Frequently Asked Questions

What is IPv4 supply-chain risk?

IPv4 supply-chain risk refers to dependencies across the commercial, registry-facing and technical relationships required to deliver usable IPv4 capacity to a customer.

Do more intermediaries always make IPv4 less stable?

No. Intermediaries can add useful capabilities such as market discovery, transaction support or specialised services. Risk increases when the additional dependencies are unclear or lack defined continuity responsibilities.

Is a first-party IPv4 model automatically safer?

No. First-party service can simplify accountability, but resilience still depends on provider capability, accurate administration, clear contracts and continuity planning.

Does a first-party provider control customer routing?

No. The customer remains responsible for operating its own network and routing policy. The provider may support registry-facing and routing-related administration where required.

Why does registry-facing responsibility matter?

Customers may rely on functions such as registry records, RPKI, reverse DNS and other administrative processes. They should understand which party is responsible for maintaining those functions in support of the service.

Does owning IPv4 eliminate supply-chain risk?

Direct holding can reduce some commercial dependencies and provide meaningful control, but it does not eliminate registry, routing, operational or administrative dependencies.

Why is IPv4 continuity important?

Public IPv4 addresses can become embedded in allowlists, APIs, banking systems, firewalls, DNS, security platforms and customer integrations. Losing the same address identity can therefore become a business-continuity event.

What should enterprises check before leasing IPv4?

Enterprises should review provider structure, upstream dependencies, registry-facing responsibility, RPKI and IRR support, reverse DNS, reputation management, renewal terms, portability and continuity obligations.

Conclusion

IPv4 supply-chain stability does not mean every service must be vertically integrated or controlled by a single organisation.

Nor does it mean brokers, marketplaces or resellers are inherently risky.

The more important issue is whether the dependencies supporting the service are:

• visible;
• necessary;
• clearly assigned;
• technically coherent;
• contractually supported; and
• designed for continuity.

IPv4 infrastructure spans several separate but connected layers:

commercial relationship + registry state + routing authorization + operational use

These layers should remain aligned without being collapsed into one source of control.

A first-party service can reduce unnecessary supply-chain complexity by making upstream responsibility clearer while allowing the customer to retain operational control of its network.

The objective is not centralised governance.

The objective is clear accountability, accurate coordination, reduced unnecessary dependency and continuity of usable IPv4 service.

Organisations that depend on stable public IPv4 capacity can explore LARUS IPv4 Leasing Continuity Assurance .

For an overview of IPv4 leasing models, read IP Leasing: How IPv4 Leasing Works, Models, Costs & Benefits .

For a comparison of brokered and direct service models, see IPv4 Broker vs First-Party IP Leasing Provider: What’s the Difference? .