bgunderlay bgunderlay bgunderlay
Sign In
123

Month: May 2026

What Is RPKI and Why It Matters for IPv4 Leasing, BYOIP, and BGP Security

Posted on by lir_auto

RPKI, or Resource Public Key Infrastructure, is one of the most important routing security technologies used on today’s Internet. It helps IP resource holders prove which Autonomous System is authorized to originate their IP prefixes, reducing the risk of unauthorized BGP announcements, route hijacks, and accidental routing failures.

The Internet depends on thousands of independent networks exchanging reachability information through the Border Gateway Protocol, better known as BGP. BGP makes global routing possible, but its original trust model did not include strong cryptographic verification of whether a network was actually allowed to announce a specific IP prefix. RPKI was developed to close part of that gap.

Key idea: RPKI does not replace BGP. It adds a cryptographic authorization layer that helps networks check whether the origin ASN in a BGP route is authorized to announce a specific IP prefix.

What Is RPKI?

RPKI stands for Resource Public Key Infrastructure. It is a public key infrastructure designed specifically for Internet number resources, including IP address blocks and Autonomous System Numbers.

Unlike the Web PKI, which is mainly used to validate domain names and website identities, RPKI validates statements about Internet routing resources. In practical terms, it allows the holder of an IP prefix to create a signed authorization showing which ASN may originate that prefix in BGP.

This signed authorization is called a Route Origin Authorization, or ROA. Network operators can then use Route Origin Validation, or ROV, to compare BGP announcements against validated ROA data.

Why RPKI Matters for Internet Routing

Without RPKI, a network may accidentally or deliberately announce IP space that belongs to another organization. If other networks accept that route, traffic can be redirected, dropped, degraded, or exposed to interception risks.

RPKI helps reduce this risk by giving resource holders a way to publish cryptographically verifiable routing intent. When a route is inconsistent with the published authorization, networks that perform Route Origin Validation can reject it or treat it with lower preference.

  • It helps prevent unauthorized origin announcements.
  • It reduces the operational impact of BGP misconfigurations.
  • It gives IP holders more control over how their prefixes are originated.
  • It supports safer multi-homing, Anycast, cloud, CDN, and DDoS protection setups.
  • It improves routing hygiene across the global Internet.

How RPKI Works

RPKI follows the allocation hierarchy of Internet number resources. IP addresses and ASNs are distributed through IANA, Regional Internet Registries, National Internet Registries, Local Internet Registries, and resource holders. RPKI certificates reflect that resource hierarchy.

A resource certificate confirms that a holder has been allocated or assigned specific IP resources. The certificate itself does not define routing policy. Instead, it allows the resource holder to create signed objects, especially ROAs, that describe which ASN is allowed to originate a prefix.

RPKI Component What It Does Why It Matters
Resource certificate Confirms control over IP address space or ASNs within the RPKI hierarchy Provides the cryptographic foundation for signed routing statements
ROA Authorizes a specific ASN to originate one or more IP prefixes Lets networks verify whether a BGP origin announcement is legitimate
RPKI repository Publishes certificates, ROAs, manifests, CRLs, and related objects Makes routing authorization data available to relying-party validators
Relying-party validator Fetches and validates RPKI data from repositories Produces validated prefix-origin data for network operators
Router using ROV Compares BGP routes against validated RPKI data Can accept, reject, or de-preference routes based on validation state

What Is a ROA?

A ROA, or Route Origin Authorization, is a digitally signed object that states which Autonomous System is authorized to originate a particular IP prefix or group of prefixes.

A typical ROA includes three key elements: the IP prefix, the authorized origin ASN, and the maximum prefix length that may be announced. For example, a resource holder might authorize AS64496 to originate 203.0.113.0/24. If more specific announcements are allowed, the ROA may include a maximum length such as /25 or /26.

Important: The maximum length field must be configured carefully. If it is too broad, it may authorize more specific announcements than intended. If it is too narrow, legitimate announcements can become RPKI-invalid.

For IP resource holders, ROA accuracy is critical. A wrong origin ASN, an incorrect maximum length, or a forgotten ROA update after a network change can cause legitimate routes to be marked Invalid by networks that enforce RPKI validation.

Route Origin Validation: Valid, Invalid, and NotFound

Route Origin Validation is the process of checking a BGP announcement against validated RPKI data. The result normally falls into one of three states: Valid, Invalid, or NotFound.

Validation State Meaning Typical Operational Response
Valid The route matches a ROA: the origin ASN is authorized and the prefix length is permitted. The route can be accepted according to the operator’s normal routing policy.
Invalid A covering ROA exists, but the route does not match the authorized ASN or allowed prefix length. Many operators reject the route or assign it a lower preference.
NotFound No relevant ROA exists for the prefix. The route is usually treated differently from Invalid; NotFound does not automatically mean malicious.

The distinction between Invalid and NotFound is important. Invalid means there is a relevant authorization record and the route conflicts with it. NotFound simply means there is no matching ROA. Since RPKI deployment is still not universal, many routes may remain NotFound.

RPKI Repositories, Validators, and Routers

Routers usually do not perform all RPKI cryptographic validation themselves. Instead, relying-party software fetches RPKI objects from repositories, validates them, and produces a set of validated prefix-origin records.

Routers then receive this validated data through the RPKI-to-Router protocol. This design keeps heavy cryptographic processing away from routers while still allowing routing policy to use RPKI validation results.

RPKI repositories were historically fetched using rsync, but RRDP, the RPKI Repository Delta Protocol, was introduced to improve scaling. RRDP uses HTTPS-based snapshots and deltas, making it better suited to caching and large-scale distribution.

RPKI vs IRR: What Is the Difference?

RPKI and Internet Routing Registries are both used in routing policy, but they are not the same. IRR data is widely used to build prefix filters and document routing intent, while RPKI adds cryptographic validation tied to Internet number resources.

Area IRR RPKI
Main purpose Publishes routing policy and route objects Cryptographically authorizes route origin
Trust model Depends on registry quality, maintainer controls, and operational discipline Follows the resource certificate hierarchy
Common object route / route6 object ROA
Operational use Prefix filter generation and routing policy documentation Route Origin Validation
Best practice Keep route objects accurate where required by peers or upstreams Create accurate ROAs and monitor validation status

In modern network operations, RPKI and IRR often coexist. Many upstreams and peers still use IRR data, while RPKI is increasingly expected for origin validation and routing security.

What RPKI Protects Against

RPKI is especially useful against unauthorized route origination. If an attacker or misconfigured network announces a prefix from an ASN that is not authorized in the ROA, networks enforcing Route Origin Validation can identify the route as Invalid.

  • Accidental prefix hijacks caused by configuration errors
  • Deliberate BGP origin hijacks
  • Some cases of incorrect route propagation
  • Misaligned routing after ASN changes or provider migrations
  • Operational mistakes involving more-specific announcements

This is why RPKI is important for ISPs, cloud providers, hosting companies, enterprises, CDNs, DDoS protection networks, and organizations using multi-homed or Anycast infrastructure.

What RPKI Does Not Solve

RPKI is powerful, but it is not a complete solution for all BGP security problems. Its most widely deployed function is origin validation. That means it checks whether the origin ASN is authorized to announce a prefix, not whether the full AS path is legitimate.

Because of this, RPKI by itself cannot fully prevent all route leaks, AS path manipulation, or policy violations. Other mechanisms and operational controls are still needed, including prefix filtering, peer review, monitoring, routing policy hygiene, and emerging technologies such as ASPA.

Practical view: RPKI should be treated as a core routing security layer, not as a single complete security system. It reduces an important class of BGP risks, but it must be combined with sound routing operations.

Common RPKI Mistakes

Most RPKI problems are operational rather than conceptual. The technology is designed to improve routing security, but incorrect records can create real reachability problems.

  • Creating a ROA for the wrong origin ASN
  • Setting the maximum prefix length too narrowly
  • Setting the maximum prefix length too broadly
  • Forgetting to update ROAs after changing transit providers
  • Announcing more-specific prefixes that are not covered by ROAs
  • Not checking validation status before a routing migration
  • Assuming NotFound means malicious or Invalid means always malicious
  • Failing to coordinate ROAs with IRR route objects and upstream filters

For businesses that lease IPv4 addresses, use BYOIP, migrate providers, or route prefixes through multiple networks, RPKI should be included in the change management process. A routing change should not be considered complete until ROAs, route objects, upstream filters, and monitoring have been checked.

RPKI Checklist for IP Resource Holders

Before creating or updating ROAs, IP resource holders should confirm the routing plan and the authorization chain. This is especially important when using leased IPv4 ranges, multiple upstreams, Anycast, or cloud and CDN providers.

Recommended RPKI checklist:
  • Confirm which ASN or ASNs will originate each prefix.
  • Confirm the exact prefix lengths that will be announced.
  • Set ROA maximum length only as broad as operationally required.
  • Check whether IRR route objects also need to be updated.
  • Validate the route before and after BGP changes.
  • Monitor Valid, Invalid, and NotFound states after deployment.
  • Include ROA updates in provider migration and BYOIP workflows.
  • Document who is responsible for future RPKI changes.

RPKI and BYOIP

RPKI is increasingly relevant in BYOIP projects. When a company brings its own IP prefix to a cloud, CDN, hosting, or DDoS protection provider, the provider may need to confirm that the prefix can be safely originated or used in its infrastructure.

A correct ROA can show which ASN is authorized to originate the prefix. If the ROA is missing, too restrictive, or points to the wrong ASN, the BYOIP onboarding process may fail or the route may be rejected by networks that enforce RPKI validation.

For leased IPv4 ranges, this becomes even more important. The organization using the range must ensure that the lease terms, authorization documents, registry data, route objects, ROAs, and provider-specific requirements all support the intended routing setup.

Need IPv4 Ranges Prepared for BYOIP or Routing?

InterLIR helps businesses lease IPv4 ranges and prepare the IP-side configuration needed for routing, BYOIP, RPKI/ROA coordination, route objects, LOA documentation, WHOIS/RDAP updates, and verification steps where applicable.

Explore InterLIR BYOIP Solutions

The Future of RPKI

RPKI has moved from a specialized routing security technology to a mainstream part of Internet operations. More networks are publishing ROAs, more operators are validating routes, and routing security initiatives increasingly treat RPKI as a baseline practice.

The next stage of routing security is likely to involve broader automation, better monitoring, cleaner operational tooling, and complementary technologies that address route leaks and AS path validation. ASPA, or Autonomous System Provider Authorization, is one emerging direction that aims to improve protection against route leaks and certain AS path problems.

RPKI does not make BGP perfectly secure, but it significantly improves one of BGP’s weakest points: the lack of cryptographic proof that an ASN is authorized to originate a prefix. For any organization that manages IP resources, RPKI is no longer optional knowledge. It is part of modern routing hygiene.

RPKI FAQ

What does RPKI mean?

RPKI means Resource Public Key Infrastructure. It is a security framework for Internet number resources that allows IP prefix holders to publish cryptographically signed routing authorizations.

What is a ROA?

A ROA, or Route Origin Authorization, is a signed object that authorizes an Autonomous System to originate one or more IP prefixes.

What is Route Origin Validation?

Route Origin Validation is the process of checking a BGP route against validated RPKI data. The route is usually classified as Valid, Invalid, or NotFound.

Does RPKI prevent all BGP hijacks?

No. RPKI helps prevent unauthorized origin announcements, but it does not validate the full AS path by itself. It should be combined with other routing security practices.

Is NotFound the same as Invalid?

No. Invalid means a relevant ROA exists but the route does not match it. NotFound means no relevant ROA was found. Many operators treat Invalid routes much more strictly than NotFound routes.

Can a wrong ROA break legitimate routing?

Yes. A wrong origin ASN or maximum prefix length can make legitimate routes appear Invalid to networks that perform Route Origin Validation.

Is RPKI important for BYOIP?

Yes. Many BYOIP workflows depend on correct routing authorization. A cloud, CDN, hosting, or network provider may require ROA updates before accepting or announcing a prefix.

Conclusion

RPKI is one of the clearest and most practical improvements to global Internet routing security. It gives IP resource holders a cryptographic way to state which ASN is authorized to originate a prefix and gives network operators a way to detect unauthorized or misconfigured announcements.

For ISPs, hosting providers, enterprises, cloud users, CDN deployments, DDoS protection setups, and organizations using leased IPv4 space, RPKI should be part of everyday routing operations. Correct ROAs, accurate route objects, careful provider coordination, and ongoing monitoring all help reduce avoidable routing risk.

RPKI does not solve every BGP security problem, but it addresses a fundamental weakness: verifying whether a route’s origin ASN is authorized. As Internet infrastructure becomes more complex and more security-sensitive, that verification is increasingly essential.

Related Articles You Might Find Useful

Bring Your Own IP Prepare IPv4 ranges for BYOIP, routing, and provider onboarding. How to Rent IPv4 Addresses Guide to leasing IPv4 addresses for business infrastructure. How to Buy IPv4 Understand the process of buying IPv4 address blocks. IPv4 Broker Support for IPv4 leasing, buying, selling, and transfer needs. IPv4 Price List Review IPv4 pricing and market-related information.

IP Reputation: How Spamhaus and Blacklists Affect IPv4 Value

Posted on by lir_auto

IP reputation has become one of the most important quality signals in the IPv4 market. In 2026, IPv4 addresses are no longer treated only as technical resources. They are bought, sold, leased and managed as scarce digital assets with their own liquidity, risk profile and revenue potential.

However, one factor is still often underestimated: reputation.

Two IPv4 blocks of the same size may look identical on paper, but they can perform very differently in the market. One block may sell quickly or generate stable leasing income. Another may face additional checks, buyer hesitation, lower utilisation or repeated complaints.

The difference often comes down to abuse history, blacklist records, email reputation and monitoring systems such as Spamhaus.

Key takeaway

IP reputation rarely creates a direct premium above the market price. But poor reputation can reduce liquidity, create negotiation pressure and make an IPv4 block harder to lease or use.

  • In IPv4 sales, reputation affects trust, due diligence, deal speed and negotiation terms.
  • In IPv4 leasing, reputation directly affects usability and revenue potential.
  • Spamhaus and other blocklists are important signals, but they should be interpreted carefully because different lists mean different things.
  • Clean IP space is more liquid. It is easier to verify, easier to deploy and easier to monetise.
  • Reputation must be protected. Even clean IPs can lose value if they are leased to high-risk users or used for abuse.

Why IP reputation matters in IPv4 transactions

At first glance, IPv4 valuation may seem simple. A block has a size, a region, a registry history and a price per IP. For many transactions, these remain the primary commercial variables.

But in practice, reputation often determines how easily a block can be used after the deal.

An IPv4 block with a stable history, no visible abuse issues and no major blacklist records is easier for a buyer or lessee to trust. It creates fewer operational concerns and usually requires less explanation during due diligence.

A block associated with spam, phishing, malware, botnet activity, proxy abuse or repeated complaints is different. Even if the legal ownership is clear and the routing history is valid, the buyer or lessee may still see additional operational risk.

This is why IP reputation does not always change the theoretical value of IPv4, but it often changes the real deal conditions.

What Spamhaus and other blacklists actually indicate

Spamhaus is one of the most widely recognised reputation and blocklist providers in the email and network abuse ecosystem. Its data is used by many mail administrators and security systems to help identify spam, malware, compromised infrastructure, suspicious sources and policy-sensitive IP ranges.

However, it is important not to treat every listing as the same type of problem.

Some listings may indicate active abuse or malicious behaviour. Others may relate to compromised hosts, spam sources, policy-based mail restrictions or IP ranges that are not expected to send email directly. For example, a policy-based listing is not the same as a confirmed spam operation.

This distinction matters in IPv4 transactions. A buyer, seller, broker or lessee should not ask only whether an IP is “blacklisted”. They should ask which list is involved, what the listing means, whether the root cause is still active and whether the issue can be remediated.

Reputation check note

A blacklist record should be treated as a risk signal, not as a complete conclusion. The right assessment depends on the type of listing, the age of the issue, the reason for the listing, the current routing status and whether the underlying abuse has been resolved.

How abuse history affects IPv4 sales

In IPv4 sales, reputation usually becomes visible during verification and negotiation.

If a block appears clean, with no major blacklist records and no obvious history of abuse, the transaction is usually easier to move forward. The buyer spends less time checking operational risks, the due diligence process is smoother and there is less pressure to renegotiate the price.

If a block has visible abuse history, the process changes. Buyers may request additional checks, ask for more details about previous use, test smaller ranges, involve technical teams or use the issue as a reason to negotiate a discount.

This does not mean that every listed or previously abused block becomes unsellable. IPv4 remains scarce, and many buyers are willing to evaluate imperfect assets. But reputation problems can make the deal slower, more conditional and more vulnerable to price pressure.

Commercial reality

Good reputation rarely increases the base market price by itself. Poor reputation, however, can reduce the effective price through negotiation, delay or lower buyer confidence.

Reputation and IPv4 liquidity

Liquidity is one of the most practical effects of IP reputation.

A clean IPv4 block is easier to present to the market. It is easier for brokers to promote, easier for buyers to approve internally and easier for technical teams to test. This can shorten the time between listing and closing.

A problematic block may still have value, but it often requires a narrower buyer profile. Some buyers may avoid it entirely. Others may accept it only at a lower price, after remediation, or for use cases where reputation is less important.

As a result, reputation does not only affect price. It affects how quickly an IPv4 asset can be converted into cash.

When reputation has less impact on IPv4 sales

Reputation does not affect every IPv4 sale in the same way.

In larger transactions, especially where buyers acquire address space as a long-term asset, the immediate operational reputation of individual IPs may be less important than total volume, registry status, transfer eligibility and price per IP.

This is especially true when the buyer plans to hold the asset, restructure it, renumber it, clean it over time or use it in environments where email reputation is not central.

However, even in these cases, reputation is not irrelevant. A major abuse footprint can still affect diligence, internal approval and the buyer’s perception of risk.

Why IPv4 leasing works differently

Leasing is much more sensitive to reputation than ownership transfers.

A buyer may acquire IPv4 space for long-term use, storage or future resale. A lessee usually needs to use the IPs immediately. If the leased block has reputation problems, the issue can become visible within hours or days.

  • Email may fail to reach recipients or may be filtered more aggressively.
  • Online services may apply additional checks or restrictions.
  • Security systems may classify traffic as higher risk.
  • Complaints may appear soon after deployment.
  • The lessee may request replacement space or cancel the service.

For this reason, reputation in leasing is not just a negotiation factor. It is a usability factor.

Reputation as a revenue factor for IP owners

For IPv4 owners, reputation has a direct economic impact.

Clean, stable and well-managed address space is easier to lease. It can support longer customer relationships, fewer complaints and more predictable monthly income.

Low-reputation space behaves differently. It may require discounts, create more support work, attract higher-risk users or remain idle even when market demand exists.

Factor Clean IP space Problematic IP space
Sales process Usually faster and easier to verify More questions, deeper checks and possible delays
Negotiation Lower risk of reputation-based discounts Higher risk of price pressure
Leasing demand Easier to lease to legitimate users May attract only limited or high-risk demand
Revenue stability More predictable monthly utilisation Higher risk of churn, complaints and idle space
Operational workload Lower support and remediation burden More monitoring, delisting and customer management

In leasing models, the key question is not only “what is this IPv4 block worth?” It is also “can this block reliably generate revenue?”

The reverse risk: leasing can damage clean IPs

There is another side to reputation risk. Even a clean IPv4 block can quickly lose value if it is leased to the wrong user.

Spam activity, phishing, malware hosting, proxy abuse, compromised servers, weak customer verification or poor abuse response can damage the reputation of leased address space. A block that was clean at the beginning of the lease may become listed or restricted during the lease period.

This is why IPv4 owners increasingly treat reputation as an asset that must be actively protected, not only checked once before a deal.

  • Usage policies help prevent high-risk activity before it starts.
  • Customer verification reduces exposure to abusive users.
  • Abuse monitoring helps identify problems quickly.
  • Clear termination rules protect the owner if the lessee violates acceptable use policies.
  • Ongoing reputation checks help preserve long-term leasing value.

What to check before buying or leasing IPv4 space

Before an IPv4 transaction, both sides should treat reputation review as part of normal due diligence.

Practical reputation checklist

  • Check major IP blocklists and reputation databases.
  • Identify which specific list is involved, not only whether a listing exists.
  • Review whether the issue is current, historical or policy-based.
  • Check abuse contacts, previous routing patterns and visible network history.
  • Ask how the block was used before the transaction.
  • For leasing, define acceptable use rules before service activation.
  • Monitor abuse reports continuously during the lease period.

This process does not eliminate all risk. But it helps buyers, sellers and lessors avoid preventable surprises.

Conclusion: IP reputation is part of IPv4 value

In 2026, an IPv4 block is not just a line in a registry database. It is an asset with history, usability and operational risk.

Spamhaus listings, abuse history and blacklist records do not automatically define the base price of IPv4 address space. But they strongly influence how the market treats that space in practice.

  • In sales, reputation affects trust, deal speed, diligence and negotiation terms.
  • In leasing, reputation affects immediate usability, customer retention and revenue potential.
  • For IP owners, reputation is a long-term asset that must be protected.

The strongest commercial position belongs to companies that understand this early. Clean, well-managed IPv4 space is easier to sell, easier to lease and easier to monetise. Poorly managed reputation, by contrast, can turn a scarce asset into an underused one.

For IPv4 owners, buyers and lessees, the conclusion is simple: reputation is not a side issue. It is part of the value of the asset.

Need to evaluate IPv4 reputation before buying, selling or leasing?

InterLIR can help you assess IPv4 block quality, review reputation risks, compare leasing and ownership options, and protect the long-term value of your address space.

Talk to InterLIR about IPv4 reputation and strategy

AI Hype as a New Argument in the IPv4 Market: What Transfer Data Shows So Far

Posted on by lir_auto

AI has become one of the newest arguments in the IPv4 market. As artificial intelligence becomes more visible across the public Internet, more commentators are linking AI growth to renewed demand for IPv4 address space.

The logic is easy to understand. Chatbots, autonomous agents, AI search tools, crawlers, automation platforms, data collection systems and distributed inference services all need to interact with existing online infrastructure. A large part of that infrastructure still depends on IPv4, so it is tempting to assume that AI growth should automatically translate into stronger IPv4 demand.

The argument is plausible. But plausibility is not the same as proof.

At InterLIR, our view is that AI is relevant to the IPv4 market, especially for leasing, proxy infrastructure, outbound connectivity and reputation-sensitive routing. However, the available March-April 2026 transfer data does not yet prove that AI has directly reshaped the IPv4 purchase market or caused broad repricing.

Key takeaway

AI may increase the operational value of clean, routable IPv4 access. But current transfer data supports a more cautious conclusion: AI is a supporting demand factor, not yet a proven primary driver of IPv4 purchase-market growth.

  • AI-related use cases are real, especially for crawling, automation, proxy infrastructure and distributed outbound traffic.
  • Transfer data does not yet show an AI-led purchasing wave. April 2026 volume was driven mainly by larger transfers, not by a surge in small flexible blocks.
  • Leasing is likely to feel the AI effect first. Flexible access is often more useful than permanent ownership for temporary or scalable workloads.
  • The market is stabilising, not breaking out. Current data points to liquidity and a firmer floor, not confirmed broad repricing.

Why AI became part of the IPv4 market story

The AI-IPv4 argument is usually built on four assumptions.

  • AI applications need access to IPv4-only and dual-stack resources. Many websites, APIs, enterprise systems and legacy services still depend on IPv4.
  • Large-scale data collection may require distributed outbound traffic. Crawlers, agents and automation platforms may need IP diversity, geographic routing and reputation management.
  • Agent-based systems can generate more automated requests than traditional human users. This may increase demand for scalable network access.
  • AI-related workloads often prefer flexibility. Companies may lease or temporarily access IPv4 space instead of committing to permanent ownership.

Taken together, these assumptions support a credible market argument: AI may increase the operational value of clean, routable IPv4 address space, especially where reputation, geography and flexible access matter.

However, this argument should not be treated as direct evidence of a broad repricing of the IPv4 market.

The commercial interest behind the AI-IPv4 argument

There is also a commercial reason why this argument is gaining visibility.

Many participants in the IPv4 ecosystem benefit from presenting AI as a new structural driver of demand. Sellers benefit from a narrative that reduces pressure to discount. Leasing platforms benefit from positioning IPv4 as a flexible infrastructure layer for AI, automation and distributed workloads. Brokers benefit when buyers believe that current prices may represent an attractive entry point before future demand increases.

This does not mean the argument is false. It means the argument should be tested against observable data.

The strongest version of the AI-related IPv4 argument is not that every chatbot or AI agent needs its own dedicated public IPv4 address. That would be too simplistic. Public IP addresses are not reliable identity units for autonomous agents. Many agents can operate behind shared infrastructure, NAT, cloud gateways, proxy layers or API-based authentication systems.

The more realistic argument is narrower: AI-related workloads may increase demand for publicly routable IPv4 access, especially for outbound Internet connectivity, crawling, API interaction, proxy infrastructure, reputation-sensitive routing and temporary scaling.

That distinction matters. It separates a credible infrastructure effect from an overstated scarcity argument.

InterLIR’s view: no direct evidence yet of AI-driven IPv4 repricing

At InterLIR, our position is that the growth of AI agents, chatbots and automation systems is relevant to the IPv4 market. But current data does not yet prove a direct causal link between AI growth and higher prices in the IPv4 purchase market.

The available March and April 2026 transfer data shows stabilisation, continued liquidity and larger transfers. It does not yet show a clear AI-specific shift in purchasing activity.

Methodology note

Public IPv4 transfer data shows the movement of address space, but it does not disclose individual transaction prices. For this analysis, several records that appeared to represent the same transfer between the same parties, on the same date and under the same transfer category were treated as one observed transaction.

This means the analysis is useful for understanding transfer volume and structure, but it should not be read as direct transaction-level pricing data.

What changed between March and April 2026

On InterLIR’s adjusted transaction-counting basis, total transferred IPv4 volume increased from 3,626,496 addresses in March to 4,863,488 addresses in April. That is a material increase of about 34.1%.

However, April was not a month of broader market activity. It was mainly a month of larger transfers.

Metric March 2026 April 2026 Change
Total transferred IPv4 volume 3,626,496 addresses 4,863,488 addresses +34.1%
Observed transactions 331 312 -5.7%
Average transaction size About 10,956 addresses About 15,588 addresses +42.3%
/17-/20 transferred volume 811,008 addresses 2,035,712 addresses +151.0%
/24 transferred volume 70,656 addresses 37,376 addresses -47.1%
M&A-related transfer volume 633,088 addresses 1,528,576 addresses +141.4%

This structure is important. More address space changed hands in April, but through fewer and larger deals. The strongest increase came from the /17-/20 segment, while /24 volume declined sharply.

That weakens the argument that April’s higher transfer volume was driven by flexible, small-block demand. Many AI-related use cases discussed in the market, including proxy pools, temporary access, distributed outbound traffic and reputation-sensitive routing, would normally be expected to support demand for smaller and easily deployable blocks. April did not show a clear increase in that segment.

The role of M&A also became more visible

The role of M&A and corporate restructuring increased significantly in April. M&A-related transfer volume rose from 633,088 addresses in March to 1,528,576 addresses in April. Its share of total transferred volume increased from about 17.5% to about 31.4%.

This makes it difficult to read April’s higher volume as direct evidence of new AI-driven buying pressure. A significant part of the increase appears to reflect corporate, structural or portfolio-related movement rather than broad open-market demand from AI infrastructure buyers.

In short, the headline volume number looks strong. But the composition of that volume tells a more cautious story.

What the transfer data actually supports

The transfer data supports several careful conclusions.

  1. The IPv4 market remains active. Large blocks are still moving, and buyers are present for meaningful volumes of address space.
  2. The market appears to be stabilising after the 2025 correction. April’s higher total volume points to liquidity, but not necessarily to rising prices.
  3. The buyer base remains diversified. Telecom operators, hosting companies, data infrastructure providers, security companies, cloud-related businesses and corporate network operators continue to appear in transfer data.
  4. AI companies are not visibly dominating purchases. Current public transfer data does not show AI companies or AI-agent infrastructure providers as the clear leading buyer category.
  5. The decline in /24 volume matters. It makes it harder to argue that flexible small-block demand has already become a visible purchase-market driver.

These conclusions do not dismiss AI as irrelevant. They simply keep the argument grounded in observable evidence.

Where AI may still matter

AI should not be ignored. The growth of automated systems, AI crawlers, agentic workflows and machine-to-machine web interaction can increase the operational need for public IPv4 access.

This is especially relevant when systems need to interact with IPv4-only services, avoid excessive concentration of traffic behind a small number of addresses, manage IP reputation or distribute outbound traffic geographically.

However, this impact is more likely to appear first in leasing, proxy infrastructure, short-term address access and reputation-sensitive routing than in large-scale permanent purchases.

The likely AI impact path

  • First: stronger utilisation of leased IPv4 space and proxy infrastructure.
  • Second: more demand for clean, reputation-sensitive routing and geographically diverse access.
  • Third: possible support for a firmer market floor if AI-related workloads become sustained and measurable.
  • Not proven yet: broad AI-driven repricing of permanent IPv4 ownership.

AI-related demand may also be partially hidden inside broader infrastructure categories. Cloud providers, hosting companies, security platforms and data infrastructure operators may buy or lease address space for mixed workloads, including AI-related customers, without those transactions appearing in public data as explicitly AI activity.

This is a real limitation of the data. The absence of a visible AI buyer category does not prove that AI has no effect. But it also does not support the stronger claim that AI has already reshaped the purchase market.

Leasing may be the first place to watch

Public leasing commentary in 2026 continues to describe the leasing segment as more resilient than the purchase market, with rates broadly around the $0.40-$0.50 per IP per month range depending on region, quality and platform. At the same time, increased available supply may create pressure on less differentiated or lower-reputation space.

This is consistent with a more nuanced view of AI demand. AI may support demand for IPv4 usage without immediately causing a broad increase in IPv4 asset prices.

In practice, AI-related workloads may help increase utilisation of leased address space, reduce sellers’ willingness to discount further, or help establish a firmer price floor. But that is different from proving that AI has already triggered a new rally in the IPv4 purchase market.

Conclusion: AI is relevant, but not yet decisive

The current AI-related argument around IPv4 has a real underlying mechanism, but it should be treated carefully.

AI agents, chatbots, crawlers and automation systems are likely to increase demand for IPv4 access in specific operational contexts. The strongest current impact is likely to be in leasing, proxy infrastructure, distributed outbound connectivity, temporary scaling and clean-address reputation.

However, the March-April 2026 transfer data does not yet support the stronger claim that AI growth has directly reshaped the IPv4 purchase market or caused broad repricing. April’s increase in total transferred volume was driven mainly by large and mid-large transfers, while /24 volume declined and M&A-related activity became more prominent.

The most accurate position is this: AI is a relevant supporting demand factor, but not yet a proven primary driver of growth in the IPv4 purchase market.

For now, AI should be viewed as one of several forces helping to stabilise the market and potentially establish a firmer price floor, rather than as confirmed evidence of a new sustained upward cycle in IPv4 purchase prices.

Planning your IPv4 strategy around AI, automation or scaling demand?

InterLIR can help you evaluate IPv4 block quality, compare leasing and ownership economics, and choose the right access model for your infrastructure needs.

Talk to InterLIR about your IPv4 strategy