bgunderlay bgunderlay bgunderlay
Sign In
123

Author: lir_auto

Can an RPKI-Valid Route Still Be Hijacked? What IPv4 Owners Should Know

Posted on by lir_auto

Your IPv4 prefix has a valid ROA. Your monitoring dashboard shows RPKI: Valid. Does that mean the route is safe? Not necessarily.

In August 2026, infrastructure used by Softaculous and Virtualizor was affected by a BGP hijack in which a more-specific /24 was announced inside a legitimate /16. Traffic was redirected to attacker-controlled infrastructure during two separate periods between August 28 and 30. The incident also enabled the attacker to obtain valid TLS certificates and contributed to a malicious Virtualizor update reaching a small number of installations. The unusual part was that the malicious route was still considered RPKI-valid.

Key takeaway: RPKI-valid does not automatically mean route-trusted.

For IPv4 owners, lessees and network operators, the incident shows why routing security needs to go beyond checking whether a route simply passes Route Origin Validation.

What Happened During the Softaculous BGP Hijack?

At approximately 20:57 UTC on August 28, 2026, a new BGP announcement appeared for: 162.55.80.0/24 That prefix sits inside the larger: 162.55.0.0/16 normally originated by Hetzner Online through AS24940. The affected /24 contained addresses used by Softaculous infrastructure, including software update systems and client-facing services. Softaculous reported two periods of incorrect routing:

Incident period Start End
First period August 28, ~20:57 UTC August 29, ~08:50 UTC
Second period August 29, ~20:57 UTC August 30, ~06:10 UTC

During these periods, traffic intended for legitimate Softaculous systems could instead be routed toward attacker-controlled infrastructure.

Why Did the /24 Override the Legitimate /16?

The reason is a fundamental rule of IP forwarding: the most-specific matching prefix normally wins. A router that sees both of the following routes will generally prefer the /24 for addresses inside that smaller range:

Route Role What happens
162.55.0.0/16 Legitimate route Covers the larger address range
162.55.80.0/24 More-specific route Preferred for traffic inside the /24

The attacker therefore did not need to replace or hijack the entire /16. A single more-specific /24 could attract traffic for the systems located inside that range. LACNIC’s technical analysis described the event as a more-specific hijack of Hetzner’s normal /16 announcement.

How a More-Specific Prefix Redirects Traffic

Normal routing

162.55.0.0/16 announced by the legitimate network

Traffic follows the /16

Legitimate infrastructure receives the traffic

During the hijack

162.55.80.0/24 appears as a more-specific route

Traffic for 162.55.80.x follows the /24

Traffic can be redirected

Caption: BGP forwarding prefers the more-specific /24 over the /16 for addresses inside that range.

How Could the Route Remain RPKI-Valid?

This is the most important part of the incident. The suspicious route was observed with an AS path resembling: … → AS6204 → AS62390 → AS24940 The rightmost ASN — the origin presented by the route — was AS24940, Hetzner’s legitimate ASN. The existing ROA also allowed prefixes within the /16 to be announced as specifically as /24. That meant two important Route Origin Validation checks succeeded:

RPKI check What the route showed Result
Is the origin ASN authorized? Origin appeared as AS24940 ✓ Valid
Is the prefix length authorized? /24 was permitted ✓ Valid
Is the complete AS path legitimate? Standard ROV does not verify this Not checked

The result was therefore:

RPKI status: Valid

The route passed origin validation even though the surrounding BGP path was associated with the hijack.

What Does Route Origin Validation Actually Check?

ROV essentially asks:

Is this ASN authorized to originate this IP prefix?

It does not prove that every autonomous system appearing earlier in the AS path represents a legitimate routing relationship. That distinction matters. An attacker who can make the authorized ASN appear in the origin position may be able to create a route that passes origin validation even though the route itself is malicious.

Why the Hijacked Route Was RPKI-Valid

ROA authorization

Prefix: 162.55.0.0/16

Authorized origin: AS24940

More-specifics allowed to /24

—

Hijacked announcement

Prefix: 162.55.80.0/24

Apparent origin: AS24940

Prefix length: /24

Path included unexpected ASes before the origin

Validation result
✓ Origin ASN matched
✓ Prefix length matched ✓ RPKI VALID
But: the complete AS path was not validated by ordinary ROV.

Should you set maxLength in your ROA?

The incident also shows why ROA configuration matters. A ROA can authorize a larger prefix while using maxLength to permit more-specific announcements. For example:

Configuration Prefix Origin ASN maxLength
Broader authorization 203.0.0.0/16 AS64500 /24
Exact authorization 203.0.0.0/16 AS64500 /16

With the first configuration, the ASN can originate more-specific prefixes down to /24 and have them pass Route Origin Validation. That may be operationally useful when the network actually advertises those more-specific routes. But if those prefixes are never used, the authorization can be broader than necessary.

RFC 9319 recommends using minimal ROAs whenever possible and generally avoiding maxLength unless there is a specific operational need. The objective is to reduce the attack surface for forged-origin sub-prefix hijacks.

Following the Softaculous incident, Hetzner changed the ROA for 162.55.0.0/16 so that its maxLength became /16, removing the previous authorization for more-specific prefixes under that ROA.

A practical question for IPv4 owners

Does your ROA authorize more-specific prefixes that your network never actually announces?

If the answer is yes, your authorization may be broader than your current routing requirements.

Not sure your ROA matches what your network actually announces? Send us the prefix and ASN and we’ll compare the ROA, live announcement and IRR objects.

Support chat

How a BGP hijack leads to valid TLS certificates

The routing hijack was only the first stage. Softaculous reported that attacker-controlled infrastructure was able to obtain new TLS certificates for affected domains because certificate-validation traffic was also routed through the hijacked network path. The incident then affected Virtualizor’s update infrastructure. Softaculous confirmed that a malicious update reached a small number of Virtualizor installations. The sequence can be summarized like this:

Stage What happened
1. More-specific BGP route appears A /24 is announced inside the legitimate /16
2. Traffic is redirected Traffic for the affected range follows the /24
3. Certificate validation is affected Validation requests also follow the hijacked route
4. Valid TLS certificates are obtained The attacker can present trusted-looking HTTPS
5. Users and systems connect Connections may not trigger obvious certificate warnings
6. Software delivery is affected A malicious Virtualizor update reaches some installations

This shows why BGP security is not limited to routers. Internet routing sits beneath services such as:

  • TLS certificate validation;
  • software repositories;
  • APIs;
  • DNS infrastructure;
  • authentication endpoints;
  • customer portals;
  • payment and billing systems.

A routing compromise can therefore become the first step in a much broader infrastructure attack.

ASPA vs ROA: what’s the difference?

This is where ASPA — Autonomous System Provider Authorization — becomes relevant. ROA and ASPA address different parts of routing security.

ROA ASPA
Main purpose Validate route origin authorization Validate provider relationships
Connects IP prefix → authorized ASN Customer ASN → authorized providers
Main question Which ASN may originate the prefix? Which providers is the ASN authorized to use?
Helps identify Unauthorized origins Unexpected provider relationships
Deployment Established Still developing

After the incident, Hetzner also added an ASPA record identifying authorized providers for AS24940. According to the technical analysis, networks performing ASPA validation could use that information to reject paths containing an unauthorized upstream relationship such as the one observed in this event. ASPA does not replace ROAs. The mechanisms protect different parts of routing information.

ROA vs ASPA

Security layer — Question it helps answer

ROA

Is this ASN allowed to originate this prefix?

ROV

Does the current BGP origin match the ROA?

ASPA

Is this provider relationship authorized?

BGP monitoring

Has the prefix, origin or AS path changed unexpectedly?

A stronger routing-security model combines these signals rather than relying on only one of them.

What to check before announcing a leased IPv4 block

Before a newly leased IPv4 block is announced, the routing state should be checked against how the block will actually be used.

What to check What to verify before announcement Why it matters
Routing history Previous origins, more-specific announcements and unusual route changes Establishes whether the block has had unexpected routing activity
Authorized origin ASN The ASN that should originate the block in the new setup Prevents a mismatch between the intended origin and the ROA
ROA configuration Authorized ASN and permitted prefix length Ensures the ROA matches the actual announcement plan
IRR route objects Existing route objects and the ASN they reference Avoids stale routing records after operational control changes
Expected announcement size Whether the block will be announced as the full prefix or as approved more-specifics Helps avoid unnecessarily broad maxLength authorization
AS-path baseline Expected upstreams and normal path structure Makes unexpected provider or path changes easier to detect
Reputation and abuse history Current blocklist status and recent abuse history Identifies non-routing risks before production use
Geolocation Whether major geolocation databases reflect the intended region Reduces regional access and service issues after deployment

If the block moves to a different ASN, transit provider, cloud environment or BYOIP setup, update the relevant routing authorization and route objects before announcing it.

Registry ownership or lease status can remain correct while the routing configuration is still outdated. The operational check should therefore be performed against the planned live announcement, not only against registry data.

RPKI-Valid Does Not Mean Route-Trusted

The Softaculous incident demonstrated an important limitation of Route Origin Validation: the malicious /24 could satisfy the ROA because the apparent origin matched the authorized ASN and the ROA permitted that prefix length.

RPKI remains an important routing-security layer, but it answers a specific question about origin authorization. It does not validate the complete AS path. For IPv4 owners, lessees and operators, the practical conclusion is to keep ROAs precise and combine origin validation with route and path monitoring.

Do not stop your routing-security checks when a route says “RPKI Valid.”

Browse available IPv4 blocks by RIR and region on the InterLIR Marketplace.

Browse IPv4 Marketplace

Sources

Why IP Geolocation Can Be Wrong After an IPv4 Transfer

Posted on by lir_auto

An IPv4 transfer changes registry data, but GeoIP providers may continue to show the old country. Learn which records matter and how to request corrections.

IP geolocation after an IPv4 transfer does not update everywhere at the same time. The Regional Internet Registry may show the new resource holder while a website, advertising platform or streaming service still assigns the block to its previous country. This can happen because registry records, routing data, operator-published geofeeds and commercial GeoIP databases are separate systems.

To correct an outdated location, the recipient should verify the RIR record, publish an accurate geofeed, check the live BGP announcement and submit evidence to the databases used by affected services. No single change can force every provider to update, and no broker can guarantee one universal correction date.

Why IP Geolocation After an IPv4 Transfer Can Be Wrong

An IPv4 address transfer changes the registration of an eligible prefix from a source organisation to a recipient organisation. It does not automatically rewrite every third-party database that has previously associated the prefix with a country, city, company or connection type.

GeoIP providers build their own datasets from multiple signals. These may include operator submissions, registry records, routing observations, network measurements, customer feedback and historical evidence. Providers use different sources, confidence rules and release schedules, so two current databases can return different answers for the same IP address.

A transfer can also be followed by a genuine change in deployment. A block previously used in one region may be deployed in another country or operated by a different network. Until providers obtain and process evidence of that change, historical location data can remain visible. However, a change of registered holder alone does not necessarily mean that the block’s geographic location has changed.

Why Does WHOIS Show the Right Country but the Website Still Shows the Wrong One?

RIR databases primarily document Internet number-resource registration and contacts. A country: value may describe an administrative or registration context rather than the physical location of every device using the prefix. It is therefore useful evidence, but it should not be treated as a definitive GeoIP record.

RFC 9632 explicitly distinguishes operator-published geofeed data from geographic hints in RIR objects. Under its discovery rules, consumers must disregard other geographic hints for the relevant address range, such as country: or geoloc:, when a geofeed is specified. This does not guarantee that every commercial provider will accept the declared location without its own checks.

The distinction matters for multinational networks, cloud infrastructure, leased address space and anycast services. The registered organisation may be in one country while users or infrastructure are distributed across several others.

Which Data Source Is My Service Actually Using: RIR, Geofeed or a GeoIP Vendor?

Source What it can show Updated by the transfer? How to correct it
RIR RDAP/WHOIS Registered holder, contacts, status and registry country data The holder record is updated through the RIR process Use the relevant RIR or sponsoring LIR procedure
Geofeed Operator-declared country, region and city by prefix Not automatically Publish an RFC 8805 geofeed and reference it through the registry’s supported mechanism
BGP Observed announcements, prefixes and origin ASNs No; routing must be reviewed separately Coordinate any required announcement changes, IRR objects and RPKI ROAs
Commercial GeoIP Vendor estimate of user or network location Not necessarily; providers process evidence independently Provide consistent evidence through each vendor’s correction channel
Online service The service’s own interpretation, API result or licensed database snapshot Not automatically Identify its data supplier or use the service’s reporting process
From transfer records to the location shown by an online service
1. RIR record
Holder and administrative data
REGISTRATION UPDATE
2. Geofeed
Operator-declared deployment location
OPERATOR-MAINTAINED
3. BGP / RPKI
Live origin and route authorisation
SEPARATE VERIFICATION
4. GeoIP vendor
Independent estimate and release cycle
INDEPENDENT PROCESSING
5. End service
Vendor feed, local database or cached API result
SERVICE-SPECIFIC UPDATES

The arrows show a practical review workflow, not automatic synchronisation or a mandatory data path. Registry, geofeed and routing checks can run in parallel. GeoIP vendors choose their own evidence sources, and online services control how they use and refresh the resulting data.

Step 1: Verify the Transfer and Registry Record

Start with the authoritative registration data for the prefix. Confirm that the transfer is complete, the recipient organisation is displayed correctly and the abuse and administrative contacts are current. If the block is subdivided for customers, make sure any permitted more-specific assignments or suballocations are also accurate.

Do not change a registry country field solely to influence a consumer website. The record should accurately reflect the purpose defined by the relevant RIR. An inconsistent or misleading registry object can make correction requests less credible rather than more effective.

Step 2: How to Create a Geofeed File (RFC 8805 Example)

RFC 8805 defines a CSV format for publishing IP location data: ip_prefix,alpha2code,region,city,postal_code. Use ISO 3166-1 alpha-2 country codes and ISO 3166-2 region codes. Only the prefix is required; leave unknown location fields empty. The postal-code field is deprecated and should remain empty.

Choose prefixes that accurately represent deployment. If parts of a /20 serve different countries, publish more-specific entries for those parts. There is no need to split a block further when the same location accurately applies throughout it.

Host the file at a stable HTTPS URL. Use the relevant registry’s supported mechanism to reference it. For RPSL objects, RFC 9632 prefers geofeed: where supported and also defines the remarks: Geofeed form.

RFC 9877 defines how geofeed links can be exposed through RDAP. Follow the relevant RIR’s procedure; do not assume that every registry offers the same field or interface.

Example geofeed entries

192.0.2.0/24,DE,DE-BE,Berlin,
198.51.100.0/25,ES,ES-M,Madrid,
198.51.100.128/25,ES,ES-B,Barcelona,

These are documentation prefixes; replace them with authorised networks and verified locations. Save the actual CSV as UTF-8 with CRLF line endings and one record per line, without a header row. The trailing commas preserve the empty postal-code field. The /25 entries describe location granularity, not a requirement to announce /25 routes separately in BGP.

Step 3: Do BGP and RPKI Affect IP Geolocation?

A correct geofeed can still conflict with the network’s live operation. Verify that the observed announcements match the agreed deployment and that the authorised origin ASN is visible. This may be the recipient’s ASN or an ASN operated by its hosting, transit or other authorised network provider. A transfer does not, by itself, require a change of origin ASN.

Coordinate the withdrawal of obsolete or unauthorised announcements where necessary. Confirm that the appropriate RPKI Route Origin Authorisations (ROAs) cover the intended origin ASN and announced prefix lengths, maintain accurate IRR route objects, and review reverse DNS and abuse contacts.

BGP does not prove a user’s physical country, and a ROA authorises route origination rather than geographic location. An ASN can operate globally, and traffic can traverse remote upstreams or Internet exchanges. An unchanged origin ASN or multiple origin ASNs are not automatically errors; investigate whether the announcements are authorised and consistent with the deployment described in the correction request.

RPKI updates pass through repository publication, validator refresh and router-cache synchronisation. RFC 8210 specifies a recommended default of 3,600 seconds (one hour) for a router to poll its RPKI cache; a cache notification can prompt an earlier query. This is not an end-to-end propagation deadline. Check the ROA’s publication and the observed validation state rather than assuming that every network will reflect the change within one or two hours. If a route is invalid, check the authorised ASN and prefix length as well as possible stale data.

An IRR change also has several stages: acceptance by the authoritative registry, replication to any mirrors, and use by an upstream provider’s route-filtering system. Their schedules differ. Confirm the object in the authoritative IRR, then check which database and filter-refresh process the transit provider actually uses.

Step 4: Submit Corrections to GeoIP Providers

Once you have verified the public records and deployment, check several databases using addresses from each deployed subprefix. Record the returned country, region, city, organisation and connection type where available. Prioritise providers that are known to supply the affected product; correcting an unrelated lookup site may have no impact.

MaxMind provides an official GeoIP location correction form for an IP or network. It reviews requests against multiple data sources and does not guarantee acceptance. IPinfo also maintains an IP geolocation correction channel. Submit the exact CIDR, verified deployment location, company-domain contact and supporting geofeed or registry links, following each provider’s requirements.

If Google products show the wrong country, use Google’s IP problem reporting process. Google states that updates may take more than a month and that it does not provide an individual follow-up. A submitted request is therefore not an immediate correction.

Step 5: How to Check If the Geolocation Fix Worked

A public GeoIP demo does not necessarily use the same database version, product tier or custom rules as the service experiencing the problem. Test the actual search engine, payment gateway, advertising platform, content service or customer application affected by the error.

Use several addresses from the prefix and repeat tests from fresh sessions where appropriate. Confirm which public IP the service actually sees, especially when a VPN, proxy or NAT gateway is involved. Some services also consider account settings, device location and previous activity, so an unexpected country is not always caused by their GeoIP database.

Keep dated screenshots or API responses, the exact tested IPs and correction-ticket references. This creates a usable escalation record and helps distinguish an outdated vendor database from a cached application result or another location signal.

How Long Does a GeoIP Correction Take?

There is no universal update period. A provider must first receive or discover the new evidence, validate it and include any accepted correction in its data. Its customer must then download a new database release or obtain a refreshed API result. A downstream platform may apply additional rules or retain older data.

Routing and registry checks support an orderly transfer, but their completion does not set the timetable for a GeoIP correction.

Layer When the change becomes visible What can delay it
RPKI ROA After publication, validator processing and router-cache synchronisation; no universal end-to-end deadline Repository errors, failed validation, refresh intervals or stale caches
IRR route object After registry acceptance; mirrors and upstream filters update separately Authentication review, replication schedules or upstream provisioning
GeoIP provider correction After review and publication; Google warns that its updates may take more than one month Conflicting evidence, review requirements or release schedules
API-client cache When the application refreshes its stored result; there is no standard cache lifetime Custom TTL, additional cache layers or results stored without automatic refresh
Downloaded GeoIP database When the customer downloads and deploys a build containing the correction Update schedules, failed downloads or delayed deployment

Allow for provider-specific review and downstream update delays rather than assuming that the country will change when the RIR approves the transfer. Some services may take weeks or longer. Monitor progress by provider and avoid promising customers a single completion date.

A vendor API and a downloaded database behave differently. An API may expose corrected data once it is available in that product, but the customer application may retain its previous answer according to its cache policy. A local database remains unchanged until the customer downloads and deploys another build.

MaxMind’s database-update guidance recommends automation and checking periodically throughout the day for releases, including off-schedule updates. Its sample twice-weekly cron schedule is an example of customer-side download automation, not a correction deadline. If the vendor’s own lookup is correct but the end service is still wrong, check the database product, build date, cache policy and other location signals used by that service.

Not Sure Your Geofeed, Routing and Registry Data Agree?

Send us the prefix and we’ll check the public RIR record, geofeed, BGP origin, RPKI status and the main GeoIP databases for conflicting signals.

Check My IP Block

Common Reasons a Correction Fails

  • the transfer is complete, but an obsolete more-specific record still identifies the previous organisation;
  • the geofeed is unreachable, malformed or not discoverable through the registry or the provider’s submission process;
  • one geofeed row assigns a mixed-location block to a single country;
  • the observed announcements conflict with the deployment described in the request;
  • the requested country reflects the company’s registered address rather than the actual deployment;
  • only one GeoIP vendor was contacted while the affected service uses another source;
  • the provider has corrected its data, but the downstream service still uses an older database or cached result;
  • the service’s displayed country is influenced by account or device settings rather than IP geolocation alone.

GeoIP Checklist Before and After an IPv4 Transfer

Before the transfer

  • check representative addresses across the full prefix and relevant more-specifics in several GeoIP databases;
  • record current RIR, BGP, RPKI, IRR and geofeed data;
  • define the intended deployment locations and the prefixes to which they apply;
  • agree on technical cooperation, authorised origin ASNs and any required announcement withdrawals or changes;
  • review IP reputation as a separate risk; accurate geolocation does not establish that a block is free of abuse history or suitable for a particular service.

After the transfer

  • verify the recipient and contacts in RIR records;
  • publish or update an accurate geofeed and reference it using the registry’s supported mechanism;
  • verify BGP, RPKI, IRR and reverse-DNS records and complete any required changes;
  • submit GeoIP corrections with consistent evidence where location data is outdated;
  • test the affected customer-facing services and track unresolved discrepancies by provider.

Organisations planning to buy IPv4 address space should include geolocation verification in the transfer plan. Document the actual deployment, the services that need to recognise it correctly and the acceptable lead time before deployment.

Need IPv4 Space for a Specific Region?

Browse available IPv4 blocks on the InterLIR marketplace and find options for your next acquisition.

Browse IPv4 Marketplace

Sources and Further Reading

LACNIC IPv4 Transfers: New Market Liquidity

Posted on by lir_auto

LACNIC IPv4 Transfers: A New Source of Liquidity in the IPv4 Market

LACNIC IPv4 transfers became one of the most important IPv4 market signals in 2025. Outbound inter-RIR volume from the region increased from about 142,000 IPv4 addresses in 2024 to about 7.94 million addresses in 2025.

The key change was not simply more transactions. It was the appearance of large IPv4 blocks that could influence supply, buyer expectations, pricing behavior, and global IPv4 sourcing strategies.

The global IPv4 market has operated under scarcity conditions for many years. Regional Internet Registries have little or no freely available IPv4 space left, while demand remains strong across cloud infrastructure, hosting, data centers, ISPs, CDNs, corporate networks, VPN platforms, and other services that still depend on IPv4.

As a result, the secondary IPv4 market has become more important. Companies now lease, buy, sell, and transfer IPv4 address blocks through structured transactions between existing holders.

Traditionally, most attention has focused on the ARIN, RIPE NCC, and APNIC regions. These markets have been more familiar to buyers and brokers, with higher transaction volumes and more predictable transfer experience.

LACNIC, by contrast, has often been viewed as a less active and more complex region. The address space existed, but the market appeared less transparent and the transfer process less predictable.

Quick answer: LACNIC is becoming more relevant in the global IPv4 market because NRO inter-RIR transfer data through Q1 2026 confirms a major 2025 increase in outbound IPv4 volume from the region. LACNIC is not necessarily the busiest market by number of transfers, but it is emerging as an important source of large-scale IPv4 liquidity.

Key takeaways about LACNIC IPv4 transfers

1

Volume changed faster than transfer count

LACNIC outbound inter-RIR transfer count grew moderately, but address volume increased more than 50-fold.

2

Large IPv4 blocks matter most

A few large blocks can affect market liquidity more than many small /24 or /23 transfers.

3

ARIN demand remains important

A major part of LACNIC’s 2025 outbound volume moved toward the ARIN region.

4

Due diligence is essential

LACNIC-origin IPv4 blocks require careful checks of registry status, documentation, routing, RPKI, and reputation.

[Insert Image/Infographic: “LACNIC outbound inter-RIR IPv4 transfers in 2024 vs 2025 — transfer count vs address volume.”]

What changed in the LACNIC IPv4 market?

According to NRO inter-RIR transfer statistics, cumulative outbound IPv4 transfers from LACNIC stood at about 142,000 IPv4 addresses across 64 transfers by the end of 2024. By the end of 2025, this had increased to approximately 7.94 million IPv4 addresses across 93 transfers.

The latest available NRO report for Q1 2026 shows the same LACNIC outbound inter-RIR totals, which means the key market shift still belongs to 2025, while 2026 currently confirms rather than extends that trend.

At the same time, the number of outbound inter-regional transfers increased only from 64 to 93. This distinction is important: the change was not driven by a sudden wave of small transfers, but by the emergence of large address volumes.

Metric End of 2024 End of 2025 Q1 2026 status
Cumulative outbound inter-RIR transfers from LACNIC 64 93 93
Cumulative IPv4 addresses transferred outbound ~142,000 ~7.94 million ~7.94 million
Market interpretation Limited historical outbound liquidity. Major large-block liquidity signal. 2026 confirms the shift, but does not yet show further growth.

Why volume matters more than transfer count

In the IPv4 market, the number of transactions does not always show real liquidity. Dozens of small /24 or /23 transfers can create operational activity, but they may not materially change the supply balance.

Large blocks are different. A /16 contains 65,536 IPv4 addresses. A group of blocks comparable to a /15, /14, or larger can influence buyer expectations, seller behavior, negotiation strategy, and market pricing.

Key market insight: LACNIC does not need to become the busiest RIR by transfer count to become important. Its strategic value may come from large IPv4 blocks that were previously less visible to the global market.

Why LACNIC is becoming a source of IPv4 liquidity

The 2025 shift does not mean the entire LACNIC region is suddenly selling off IPv4 resources. A more accurate interpretation is that some large holders have become more active or more willing to bring address space to the global market.

Several factors help explain why LACNIC IPv4 transfers are now receiving more attention.

1. Underused historical IPv4 holdings

Many organizations received IPv4 addresses years ago, when they were primarily treated as technical infrastructure rather than high-value assets. Some of these resources may now be underused, inefficiently distributed, or no longer aligned with the holder’s business model.

As prices for large blocks corrected from earlier highs, some holders gained an incentive to monetize IPv4 resources instead of waiting indefinitely.

2. Wider global demand

IPv4 demand exists inside Latin America and the Caribbean, but local buyers may not always be ready to absorb very large blocks quickly. The global market is broader.

A buyer from the ARIN, RIPE NCC, or APNIC region may have a larger budget, a more urgent infrastructure need, or a stronger ability to use a large address volume. For the holder of a large block, an inter-RIR transfer can therefore be more attractive than a long search for a local buyer.

3. More practical transfer experience

LACNIC transfers were often perceived as complex because inter-regional transfers require coordination between two RIRs, verification of the seller, confirmation of the buyer’s readiness, complete legal documentation, and synchronized registry updates.

Today, professional IPv4 market participants have more experience with this process. It is becoming clearer which documents must be prepared, where delays usually occur, and how the seller, buyer, broker, and registries should coordinate each step.

4. A formal inter-RIR transfer path

LACNIC allows inbound and outbound inter-regional IPv4 transfers without requiring a merger or acquisition between the companies involved. This gives holders a formal policy path to bring IPv4 address space to external buyers.

The policy path does not make every transaction simple, but it creates a procedural foundation. Once the market learns how to use that foundation, larger transactions become easier to structure and close.

Brazil, Mexico, and national registry considerations

Brazil deserves particular attention because it represents the largest share of delegated IPv4 space in the LACNIC region. Mexico is also a major regional holder.

Operationally, Brazil and Mexico require additional attention because organizations in those countries work through their corresponding National Internet Registries for resource procedures. For large IPv4 transfers, this means the documentation path, timing, and communication flow may differ from a standard direct LACNIC case.

Practical implication

For buyers and brokers, LACNIC-origin IPv4 sourcing should not be treated as a simple listing exercise. The exact country, current resource holder, registry relationship, corporate documents, and transfer path can materially affect the closing timeline.

How a LACNIC IPv4 transfer becomes predictable

A LACNIC IPv4 transfer becomes more manageable when it is treated as a structured process rather than a sequence of unexpected obstacles.

1. Verify the seller

Confirm the legal resource holder, registry status, authority of signatories, and right to transfer the IPv4 block.

2. Confirm buyer readiness

Check the receiving RIR’s requirements, buyer eligibility, corporate documents, and justification requirements where applicable.

3. Audit the resource

Review WHOIS/RDAP records, ownership history, routing, RPKI/ROA status, IRR objects, abuse reputation, and blocklist history.

4. Prepare documentation

Collect corporate documents, authorization documents, transfer agreements, invoices, and any registry-specific forms before launch.

5. Coordinate registries

Synchronize the seller, buyer, broker, LACNIC or NIR contact, and the receiving RIR to avoid idle time between steps.

6. Plan post-transfer cleanup

Update registry data, route objects, RPKI, abuse contacts, geofeed information, and operational documentation after completion.

What buyers should check before buying LACNIC-origin IPv4

For buyers, LACNIC creates an additional source of supply. This may be especially valuable for companies looking for large IPv4 blocks and willing to work through an inter-regional procedure.

However, a LACNIC-origin block should never be evaluated only by prefix size and price. The asset must be reviewed from legal, registry, routing, and operational perspectives.

Buyer due diligence checklist

  1. Confirm the exact IPv4 prefix size and whether the block can be transferred as proposed.
  2. Verify the current holder in WHOIS/RDAP and registry records.
  3. Check ownership history and any past corporate changes.
  4. Confirm whether LACNIC, an NIR, or another registry contact is involved.
  5. Review RPKI/ROA status, IRR route objects, and BGP routing history.
  6. Check abuse reputation, blocklists, spam history, and security database records.
  7. Confirm the receiving RIR’s requirements before signing commercial terms.
  8. Plan post-transfer updates for routing, registry data, rDNS, and geolocation.

What sellers in the LACNIC region should consider

For sellers, the current market creates a window of opportunity. IPv4 addresses that were previously treated as technical resources can now be managed as liquid digital infrastructure assets.

The selling strategy matters. A large block can be sold as a whole, or it can be split into smaller ranges. Each option has different commercial and operational consequences.

Selling strategy Advantages Trade-offs
Sell as one large block Preserves scale value and simplifies the transaction structure. Requires a buyer with enough budget and operational need.
Split into smaller ranges Expands the pool of potential buyers and may improve flexibility. Increases administrative work, transfer count, timing risk, and coordination burden.

The best option depends on urgency, block quality, price expectations, registry status, buyer demand, and the seller’s willingness to participate in a more complex process.

Why brokers need local expertise in LACNIC transfers

For brokers, LACNIC is becoming a region where buyer access alone is not enough. The transaction requires procedural knowledge, country-specific awareness, and careful preparation.

A professional IPv4 broker adds value by reducing the risk that a transfer will fail, stall, or become commercially unattractive before closing.

Documentation risk

Missing or inconsistent corporate documents can delay the registry review.

Registry coordination

The seller, buyer, LACNIC or NIR, and receiving RIR must move in the correct sequence.

Reputation issues

Routing history, blocklists, and abuse records can affect buyer confidence and final pricing.

Closing timeline

Several extra months of uncertainty can affect price, payment terms, and buyer commitment.

Market outlook: will LACNIC become a sustained supply source?

The trend should not be overstated. The sharp growth in 2025 may have been connected to a limited number of large transactions rather than a broad sell-off across the region.

Still, the market has received an important signal: large volumes from LACNIC are possible, and they can be handled through formal inter-RIR transfer procedures.

The future depends on whether more holders in Brazil, Mexico, Argentina, Chile, Colombia, and other LACNIC-region countries begin to view IPv4 as a marketable asset. If they do, LACNIC may take a more important place in the global IPv4 supply structure.

If the 2025 jump proves partly temporary, the perception of the region has still changed. LACNIC is no longer just a peripheral participant in the IPv4 transfer market.

How InterLIR helps with LACNIC IPv4 sourcing

InterLIR helps make IPv4 transactions structured, verifiable, and operationally usable

For buyers, sellers, and IPv4 holders, InterLIR focuses not only on matching supply and demand, but also on the operational checks that make a transaction safer: registry status, documentation, routing readiness, reputation, RPKI, and transfer requirements.

As LACNIC becomes more relevant for large-scale IPv4 liquidity, careful preparation becomes essential. The value is not only in finding a block, but in helping the transaction close cleanly.

FAQ about LACNIC IPv4 transfers

What are LACNIC IPv4 transfers?

LACNIC IPv4 transfers are transactions in which IPv4 address blocks registered in the LACNIC region are transferred between eligible organizations. They may be intra-regional transfers within LACNIC or inter-RIR transfers involving another Regional Internet Registry.

Why is LACNIC important for the IPv4 market?

LACNIC is important because NRO inter-RIR transfer data through Q1 2026 confirms a major 2025 increase in outbound IPv4 volume from the region. This shows that LACNIC can be a source of large-scale IPv4 liquidity, especially for buyers seeking large IPv4 blocks.

Did LACNIC become the largest IPv4 transfer market?

No. The key point is not that LACNIC became the largest market by number of transfers. The important change is that the region demonstrated large-block liquidity, with millions of IPv4 addresses moving through inter-RIR transfers in 2025.

Why did LACNIC outbound IPv4 volume grow in 2025?

The growth appears to reflect the activity of large holders, stronger global demand, price correction in large blocks, and improving practical experience with LACNIC inter-RIR transfer procedures.

Are LACNIC IPv4 transfers complicated?

They can be complex, especially when large blocks, national registry procedures, inter-RIR requirements, or historical ownership issues are involved. However, the process becomes more predictable when documentation, registry status, buyer readiness, and technical due diligence are prepared in advance.

What should buyers check before buying LACNIC-origin IPv4?

Buyers should check the legal holder, registry status, WHOIS/RDAP records, ownership history, transfer eligibility, routing history, RPKI/ROA status, IRR objects, abuse reputation, blocklists, and receiving RIR requirements.

Conclusion: LACNIC is becoming a region to watch

The IPv4 market is becoming more global, and sources of supply are becoming more diverse. In this new structure, LACNIC can occupy an important niche: not necessarily as the most active region by transfer count, but as one of the most interesting regions for large-scale IPv4 liquidity.

For buyers, LACNIC offers another direction for sourcing large IPv4 blocks. For sellers, it creates an opportunity to monetize unused or underused resources. For brokers, it creates a market where careful process management can deliver meaningful value.

Against the backdrop of price correction, cautious buyers, and growing supply of large blocks, LACNIC is no longer a region to ignore. In 2025, it demonstrated that it can bring millions of IPv4 addresses to the global market.

Why Does an IP Address Show the Wrong Country? IP Geolocation Explained

Posted on by lir_auto

IP geolocation is an estimate, not a physical property inside an IP address. When an IP address shows the wrong country, the problem is usually caused by outdated databases, old usage history, routing changes, missing geofeed data or inconsistent provider records.

For companies leasing, buying or moving IPv4 resources, wrong IP geolocation can create customer complaints, access blocks, fraud checks, regional content errors and support costs.

Businesses often ask the same question after deploying a new IPv4 block: why does this IP address show the wrong country? The routing may be technically correct, the server may be online and the documentation may be valid, but websites and applications may still identify the address as being located somewhere else.

The reason is simple: IP geolocation providers do not read a built-in country field from the IP address. They estimate location using multiple data sources. Those sources can be outdated, incomplete or interpreted differently by each provider.

Quick answer: an IP address can show the wrong country because IP geolocation databases are based on estimates from registry data, routing signals, geofeeds, historical usage, network measurements and correction requests. If those signals lag behind a lease, transfer or routing change, different services may show different locations.

Key takeaways about IP geolocation

1

IP addresses do not contain location

IP geolocation is inferred from external sources, not encoded inside the address.

2

Databases update at different speeds

One platform may show the correct country while another still uses older IP geolocation data.

3

Geofeeds reduce guesswork

A geofeed gives providers a structured prefix-to-location source for IP geolocation.

4

Wrong location has business impact

Incorrect IP geolocation can trigger access blocks, fraud alerts and regional service errors.

What is IP geolocation?

IP geolocation is the process of estimating the geographic location of an IP address. The estimate may include country, region, city or network-level information, depending on the database and use case.

An IP address itself does not contain a country, city or street address. There is no field in an IPv4 or IPv6 address that says where the user, server or company is physically located. IP geolocation companies build location estimates from signals such as RIR records, WHOIS and RDAP data, BGP routing, traceroutes, ISP information, historical use, geofeeds and user-submitted corrections.

This is why IP geolocation is not exact science. It is a data pipeline. When the inputs are stale or inconsistent, the output can be wrong.

Why an IP address shows the wrong country

Cause What happens Typical fix
Outdated IP geolocation database The database still reflects the old country or previous network. Submit corrections and publish accurate geofeed data.
Previous use in another country Old history follows the IPv4 block after lease, transfer or reassignment. Audit locations before deployment and request updates early.
Different provider methodologies One website shows Germany, another shows the Netherlands, another shows France. Check multiple vendors and correct the highest-impact databases.
Missing geofeed Providers rely on indirect signals because no structured operator data is available. Publish a valid geofeed and reference it where supported.

IP geolocation source 1: outdated databases

The most common reason an IP address shows the wrong country is simple delay. IP geolocation providers update their databases on different schedules. If an IPv4 block was recently leased, transferred, moved to a new ASN or deployed in another country, some databases may still show the previous location.

This is why different websites can show different results for the same IP address. A fraud prevention tool, search engine, streaming platform and analytics provider may each rely on a different IP geolocation vendor or database version.

IP geolocation source 2: old IPv4 history

IPv4 address blocks often have long histories. A prefix may have been used by one provider in one country for years, then leased or transferred to another organization in another region. The registry data may update quickly, but IP geolocation systems may still associate the prefix with the old location.

This is especially common in the IPv4 secondary market. The commercial control of an IP block may change faster than all external databases, security platforms and content systems can react.

IP geolocation source 3: different data sources

There is no single global IP geolocation authority. Providers use their own methods and datasets. Some place more weight on registry data. Others use routing signals, network measurements, customer submissions, geofeeds or historical patterns.

Because methodologies differ, IP geolocation results can differ. That does not always mean one provider is broken. It often means the available signals point in different directions or were updated at different times.

IP geolocation source 4: network infrastructure location

Sometimes the business location and infrastructure location are not the same. A company may be registered in one country, lease IPv4 addresses from a marketplace, announce the prefix through a different ASN and host servers in a data center in another country.

Some IP geolocation systems may classify the address based on the network infrastructure location. Others may infer location from the resource holder, registry information or user traffic patterns. The result can look inconsistent to customers.

IP geolocation source 5: missing or incorrect geofeed data

A geofeed is a CSV file that maps IP prefixes to geographic information such as country, region and city. RFC 8805 describes the self-published geofeed format and explains that network operators can publish prefix-to-location mappings for interested parties to consume.

Without a geofeed, IP geolocation providers may rely on less direct signals. With a correct geofeed, the operator gives providers a machine-readable source that can reduce guesswork. A geofeed does not guarantee instant correction everywhere, but it makes corrections more scalable and consistent.

Example geofeed entry

203.0.113.0/24,DE,DE-BE,Berlin,

The example means that the prefix should be associated with Germany, the Berlin region and the city of Berlin. The exact data should match operational reality and should not expose overly precise information about individual users.

IP geolocation source 6: routing and ASN changes

BGP routing changes can influence IP geolocation. When a prefix moves to a new origin ASN, a new upstream provider or a new geography, some systems may temporarily infer a different location. These changes are common during migrations, new IPv4 leases, provider changes and regional expansions.

Routing stability helps IP geolocation providers build confidence in location data. Frequent origin changes, inconsistent route objects or missing RPKI/ROA records can make the onboarding process harder.

Why wrong IP geolocation matters

Wrong IP geolocation is not just a cosmetic issue. It can affect customer access, platform trust and revenue. A user may be asked for extra verification because a login appears to come from a different country. A streaming or content service may apply the wrong region. An ad platform may misclassify traffic. A compliance-sensitive service may apply the wrong rules.

Access problems

Customers may be blocked, challenged or routed to the wrong regional service.

Fraud checks

Legitimate sessions may look suspicious because the IP location does not match user context.

Support workload

Support teams may receive complaints that are hard to diagnose without geolocation checks.

Business reporting

Analytics, advertising and compliance systems may classify traffic incorrectly.

How to improve IP geolocation accuracy

No company can force every IP geolocation provider to update instantly. But there are practical steps that improve accuracy and reduce confusion.

1. Publish a geofeed

Provide structured prefix-to-location data in the RFC 8805 format and keep it current when prefixes move.

2. Reference geofeed data

RFC 9632 specifies how geofeed data can be discovered through RPSL inetnum objects and optionally authenticated using RPKI.

3. Keep registry records clean

Review WHOIS and RDAP information, abuse contacts and organization details so databases do not rely on stale signals.

4. Stabilize routing

Use consistent BGP announcements, route objects and RPKI/ROA records so location signals are easier to interpret.

5. Contact major providers

Submit corrections to the IP geolocation providers that matter most for your customers and applications.

6. Monitor after deployment

Check several databases during the first days and weeks after a lease, transfer or ASN migration.

IP geolocation checklist for leased or acquired IPv4

When a company leases or acquires IPv4 address space, IP geolocation should be checked before customer traffic starts. The best time to fix wrong-country data is before users notice the problem.

Pre-deployment checklist

  1. Check the prefix across multiple IP geolocation databases.
  2. Record country, region and city mismatches.
  3. Confirm the intended infrastructure location and customer geography.
  4. Publish or update the geofeed before production traffic starts.
  5. Review WHOIS, RDAP, route objects and RPKI/ROA records.
  6. Submit correction requests to high-impact providers.
  7. Monitor changes after routing goes live.

How InterLIR helps with IP geolocation issues

InterLIR helps make IPv4 resources usable, not just available

When businesses lease, buy or transfer IPv4 space, InterLIR helps them think beyond availability and price. Operational readiness includes routing, authorization, reputation and IP geolocation accuracy.

For customer-facing services, correcting wrong-country IP geolocation before production can reduce access issues, support tickets and trust problems.

IP geolocation should be part of the onboarding workflow for any leased or acquired IPv4 block. The earlier the location data is checked, the easier it is to avoid customer-facing disruption.

FAQ about IP geolocation and wrong country results

Why does my IP address show the wrong country?

Your IP address may show the wrong country because IP geolocation databases rely on estimates. The database may still use old location data, previous usage history, outdated routing signals or missing geofeed information.

Does an IP address contain its physical location?

No. An IP address does not contain a built-in physical location. IP geolocation providers infer location from external data sources such as registry records, routing data, geofeeds and correction reports.

Why do different websites show different IP locations?

Different websites may use different IP geolocation vendors or database versions. One provider may update quickly while another provider still shows older location data.

Can a geofeed fix wrong IP geolocation?

A geofeed can improve IP geolocation accuracy by giving providers a structured source of prefix-to-location information. It does not guarantee instant correction across every database because each provider has its own validation and update process.

How long does an IP geolocation correction take?

The timing depends on the IP geolocation provider. Some corrections may appear quickly, while others may take days or weeks depending on the provider’s update cycle, validation process and data sources.

Conclusion: wrong IP geolocation is a data problem

When an IP address shows the wrong country, the address itself is usually not broken. The problem is usually that one or more IP geolocation data sources are outdated, incomplete or inconsistent.

Businesses can improve IP geolocation accuracy by keeping registry information clean, publishing geofeed data, maintaining stable routing, submitting corrections to major providers and monitoring results after IPv4 leasing, transfer or reassignment. For companies that rely on customer-facing infrastructure, this work should be part of normal IPv4 onboarding.

IPv4 Leasing Myths: What Businesses Need to Know in 2026

Posted on by lir_auto

IPv4 leasing is no longer a temporary workaround for companies that cannot buy address space. In 2026, it is a normal infrastructure option for hosting providers, cloud platforms, ISPs, VPN services, SaaS products, data centers and enterprises that still need reliable IPv4 connectivity.

The real question is not whether leased IPv4 addresses are worse than purchased ones. The real question is whether the IPv4 block is clean, correctly authorized, securely routed, properly documented and actively monitored.

The IPv4 market exists because the free supply of IPv4 addresses has been exhausted for years. RIPE NCC announced in 2019 that it had run out of available IPv4 addresses and could only allocate small amounts of recovered space through a waiting list. IPv6 adoption continues to grow, but many internet services still operate in dual-stack environments where IPv4 and IPv6 coexist.

This is why IPv4 leasing remains important. Businesses need address resources for hosting, cloud infrastructure, customer onboarding, regional expansion, BYOIP projects, email platforms, proxy networks, security services and migration work. Buying IPv4 may be right for some long-term strategies, but IPv4 leasing often gives companies more flexibility and lower upfront cost.

Quick answer: the most common IPv4 leasing myths are that leased addresses are lower quality, only suitable for small companies, unsafe for long-term use or irrelevant because IPv6 will replace IPv4 immediately. In practice, IPv4 leasing quality depends on reputation, routing, RPKI/ROA, documentation, abuse handling, geolocation and provider reliability.

Key takeaways about IPv4 leasing myths

1

Ownership is not quality

A leased IPv4 block can perform well when reputation, routing and documentation are clean.

2

Flexibility has value

IPv4 leasing helps companies scale up, test markets or reduce unused address capacity.

3

IPv6 does not remove IPv4 today

IPv6 is growing, but many customers, networks and platforms still require IPv4 reachability.

4

Provider quality matters

Contracts, support, RPKI, abuse handling and transparency define operational readiness.

Why IPv4 leasing remains relevant in 2026

The internet is moving toward IPv6, but it is not moving at the same pace everywhere. Google publicly measures the percentage of users that access Google over IPv6, which shows that IPv6 deployment is significant but still uneven across regions and networks. That unevenness keeps IPv4 operationally important for many production services.

For businesses, IPv4 leasing solves a practical problem: they need usable IPv4 address space now, but they may not want to buy permanent resources before demand is proven. A company may need a /24 for a regional deployment, several prefixes for customer separation or additional space for a short-term migration. In those cases, IPv4 leasing can be faster and more capital-efficient than a purchase.

The mistake is treating IPv4 leasing as a commodity transaction. A low monthly price is not enough. The provider must be able to support clean authorization, correct routing, stable registry information, abuse response and reputation monitoring.

IPv4 leasing myth map: what businesses often get wrong

IPv4 leasing myth Reality What to check
Leased IPs are inferior Quality depends on reputation, routing and management, not only ownership. Blacklist status, route visibility, rDNS, geolocation, abuse history.
IPv4 leasing is only for startups Large companies also lease for flexibility, projects and regional growth. Contract term, renewal rules, escalation process, ASN compatibility.
IPv6 will remove IPv4 demand soon Dual-stack operation remains common because IPv6 adoption is uneven. Customer regions, partner networks, application dependencies.
All providers are the same Operational support can be the difference between quick deployment and weeks of delay. LOA handling, RPKI/ROA support, routing help, abuse process, reputation checks.

IPv4 leasing myth 1: leased IP addresses are lower quality

A leased IPv4 address is not automatically worse than a purchased IPv4 address. From the perspective of most users and online services, the important question is how the IP address behaves. If the prefix has clean reputation, valid routing, correct records and responsive abuse handling, its lease status is usually invisible in daily use.

Problems appear when a leased block has unresolved reputation debt, outdated geolocation, missing ROAs, inconsistent route objects or poor documentation. The same problems can also happen with owned address space. Ownership alone does not make a prefix clean.

Quality signals for IPv4 leasing

  • Clean DNSBL and security reputation checks.
  • Valid LOA and clear authority to announce the prefix.
  • Correct RPKI ROA records for the intended origin ASN.
  • Accurate route objects and registry information.
  • Reverse DNS support where the use case requires it.
  • Clear abuse contact and escalation path.
  • Geolocation review before production traffic starts.

IPv4 leasing myth 2: leasing is only for small companies

IPv4 leasing is attractive to smaller companies because it reduces upfront cost. But that does not make it a small-company-only model. Larger providers use IPv4 leasing when they need flexibility, faster access to resources or separation between projects, customers and regions.

A cloud provider may lease addresses to test a new geography. A hosting company may lease a clean /24 for a new customer segment. A SaaS platform may need separate address ranges for email, application traffic and security controls. In these cases, IPv4 leasing is not a sign of weakness. It is a way to match infrastructure capacity to actual business demand.

IPv4 leasing myth 3: IPv6 will make IPv4 leasing unnecessary soon

IPv6 growth is real and important. Still, IPv4 leasing remains relevant because many networks, customers and services continue to depend on IPv4 connectivity. Even organizations that support IPv6 often need dual-stack operation so that IPv4-only users can still reach them.

The practical strategy is not to ignore IPv6. The practical strategy is to plan for both realities: deploy IPv6 where possible and maintain reliable IPv4 reachability where customers, partners or legacy systems still require it.

IPv4 leasing myth 4: a leased IPv4 block can be taken away at any time

This fear usually comes from unclear contracts or unreliable suppliers. A reputable IPv4 leasing provider should define the lease term, renewal process, payment terms, acceptable use rules, abuse handling process and notice periods. When those terms are clear, IPv4 leasing can support stable long-term infrastructure planning.

Risk increases when a business leases from an informal source without proper documentation. Missing authority, unclear LOA terms or poor communication can delay routing, create provider disputes or lead to unexpected service interruption. The solution is not to avoid IPv4 leasing. The solution is to work with a provider that treats documentation as part of the product.

IPv4 leasing myth 5: once the prefix is delivered, the work is finished

Receiving an IPv4 block is only the beginning. The block must be prepared, announced, monitored and maintained. This is where many IPv4 leasing mistakes happen. A technically assigned range can still fail operationally if routing, DNS, geolocation or reputation are ignored.

Routing readiness

Check origin ASN, BGP visibility, route objects and RPKI/ROA before relying on the prefix.

Reputation readiness

Review blacklist status, abuse history and email deliverability before assigning the block to customers.

Geolocation readiness

Compare major geolocation databases and publish or update geofeed data when location accuracy matters.

IPv4 leasing myth 6: all IPv4 leasing providers are the same

IPv4 leasing providers can differ significantly. Some only provide access to an address block. Others help with authorization, routing coordination, RPKI, abuse handling and operational support. That difference matters when a business needs production-ready address space.

A low price can become expensive if the block triggers fraud filters, fails route validation, shows the wrong country, has unresolved blacklist history or lacks a responsive support channel. The total cost of IPv4 leasing includes the time required to make the block usable.

IPv4 leasing myth 7: IP reputation does not matter

IP reputation matters for many use cases, especially email, hosting, VPN, proxy, SaaS, security and customer-facing platforms. If an IPv4 block was previously associated with spam, phishing, malware, abusive proxy use or scanning, some services may continue to treat the range with caution after a lease begins.

Reputation is not fixed forever, but it must be managed. Businesses should check major blocklists, review abuse signals, monitor customer activity and respond quickly to complaints. For email use cases, reputation work should include SPF, DKIM, DMARC, reverse DNS, gradual warmup and bounce monitoring.

IPv4 leasing due diligence checklist

1. Verify documentation

  • Confirm the resource holder and authority to lease.
  • Review LOA terms and renewal conditions.
  • Check WHOIS or RDAP information.
  • Confirm abuse contact details.

2. Verify routing

  • Confirm the intended origin ASN.
  • Create or update RPKI ROAs.
  • Review route objects and maxLength.
  • Monitor BGP after announcement.

3. Verify reputation

  • Check DNSBL and security reputation tools.
  • Review historical abuse indicators where available.
  • Test email behavior before production use.
  • Monitor abuse reports after onboarding.

4. Verify geolocation

  • Check country and city results across providers.
  • Publish or update geofeed data if needed.
  • Submit correction requests to key databases.
  • Allow time for propagation.

How InterLIR helps with IPv4 leasing

InterLIR helps make IPv4 leasing operationally ready

InterLIR connects businesses with IPv4 leasing, purchasing and monetization options, while also paying attention to the practical issues that decide whether a prefix is usable in production: authorization, routing, reputation, geolocation and support.

For companies that need IPv4 address space, this reduces the risk of treating IPv4 leasing as a simple price-per-IP transaction.

Good IPv4 leasing is not just about receiving addresses. It is about receiving address space that can be announced, trusted, monitored and supported. That is where provider experience matters.

FAQ about IPv4 leasing myths

Is IPv4 leasing safe for business infrastructure?

IPv4 leasing can be safe for business infrastructure when the lease terms, authorization, routing, RPKI/ROA, reputation and support process are clear. The main risk is not leasing itself, but using poorly documented or poorly managed address space.

Are leased IPv4 addresses worse than purchased addresses?

No. Leased IPv4 addresses are not automatically worse than purchased addresses. A clean, well-routed leased prefix can work better than an owned prefix with poor reputation or outdated records.

Why do large companies use IPv4 leasing?

Large companies use IPv4 leasing for flexibility. It helps them expand capacity, test regions, isolate customer traffic, support migrations or avoid buying permanent address space before the business case is clear.

Will IPv6 end IPv4 leasing?

IPv6 will reduce long-term dependence on IPv4, but it has not made IPv4 leasing irrelevant. Many networks and services still require IPv4 reachability, so dual-stack planning remains common.

What should I check before leasing IPv4 addresses?

Before leasing IPv4 addresses, check ownership authority, LOA, WHOIS or RDAP records, RPKI/ROA, route objects, BGP visibility, DNSBL status, geolocation accuracy, reverse DNS support and abuse response process.

Conclusion: treat IPv4 leasing as an operational decision

The biggest IPv4 leasing myths come from focusing too much on ownership and too little on operations. Whether a block is leased or owned, businesses need clean reputation, correct routing, reliable documentation, active monitoring and responsive support.

For many organizations in 2026, IPv4 leasing is a practical way to access scarce address resources without heavy upfront investment. The best results come from choosing a provider that understands not only the IPv4 market, but also the operational details that make address space ready for real infrastructure.

Acquired IPv4 Reputation: Blacklists & Hidden Costs

Posted on by lir_auto

The Hidden Costs of Acquired IPv4: Geolocation Mismatch, Blacklists and Reputation Debt

Acquired IPv4 reputation can determine whether a leased or purchased IP block is ready for production. Every prefix carries operational history: previous routing, outdated geolocation data, blacklist exposure, abuse reports and reputation signals.

For companies leasing, buying or transferring IPv4 resources, these hidden factors can affect email deliverability, user access, fraud checks, compliance reviews and infrastructure reliability.

The global shortage of IPv4 addresses has created an active secondary market. Companies lease, buy and transfer IPv4 blocks to support hosting, cloud infrastructure, SaaS platforms, email systems, VPN services, CDN deployments and other internet-facing services.

At first glance, acquiring IPv4 space may look like a straightforward process: verify the seller or lessor, receive a Letter of Authorization, update WHOIS or RDAP records, configure routing and start using the addresses.

In practice, an IPv4 block is not a blank technical asset. Previous routing, outdated geolocation data, DNSBL listings, abuse reports and poor IP reputation can follow the block after a transfer or lease.

Quick answer: the main hidden costs of acquired IPv4 are geolocation mismatch, blacklist exposure and reputation debt. These issues can disrupt access to online services, reduce email deliverability, trigger fraud filters and increase support workload after deployment.

Acquired IPv4 reputation is the combined effect of a prefix’s previous use, abuse history, blacklist status, geolocation records and routing background. Even when ownership or leasing documentation is correct, the wider internet may still evaluate the block based on its past.

This is why IPv4 acquisition should not be treated only as a pricing decision. Whether a company leases IPv4 addresses, buys a prefix for long-term use or prepares address space for customer-facing infrastructure, it needs a proper technical and reputation check before production traffic starts.

Key takeaways

1

Geolocation can lag

IPv4 geolocation may remain outdated for weeks or months after a prefix moves to a new country, network or provider.

2

Geofeeds reduce guesswork

Geofeeds give geolocation providers a structured source of prefix-to-location information.

3

Reputation follows the block

Transferred or leased IP space may inherit abuse history, blacklist records or poor email reputation.

4

Routing must be secured

RPKI/ROA, route objects and proper authorization help reduce routing and onboarding risks.

What “acquired IPv4” really means

In this article, acquired IPv4 means any IPv4 address space that an organization starts using after it was previously controlled, routed or used by another party.

Leased IPv4 prefixes
Purchased IPv4 blocks
Transferred resources
Brokered address space
Marketplace IPv4 deals
Customer-facing IP ranges

The commercial status of the block may change quickly, but the internet ecosystem does not update instantly. Geolocation databases, mail filters, security platforms, fraud systems and reputation tools may continue to treat the addresses according to their previous history.

This matters for companies using IPv4 space for real infrastructure. A prefix can be technically routed correctly and still cause business problems if banks, SaaS platforms, streaming services, mail providers or fraud prevention systems classify it incorrectly.

Risk map: where hidden IPv4 costs appear

Risk area What can go wrong Business impact
Geolocation The IP appears to be in the wrong country, region or city. Blocked access, fraud checks, wrong content region, customer complaints.
Blacklist history The prefix was previously associated with spam, malware, phishing or abuse. Email rejection, blocked traffic, security reviews and compliance delays.
Routing records ROAs, route objects or origin ASN records are missing, outdated or inconsistent. BGP issues, invalid announcements, failed provider verification.
Documentation LOA, WHOIS/RDAP or authorization details are incomplete. Deployment delays, failed onboarding and additional manual verification.

Geolocation mismatch: when an IP appears to be in the wrong country

IP geolocation databases do not work like GPS. They estimate location from a combination of signals, including WHOIS and RDAP records, routing data, traceroutes, user-submitted corrections, commercial datasets and geofeeds.

When a prefix is reallocated, transferred or announced from a new network, it may be operationally used in one country while still being listed in another country by major geolocation providers.

This creates an IPv4 geolocation mismatch: the network operator expects the block to be treated as one location, while websites, applications and security systems see a different location.

Common consequences of incorrect IP geolocation

  • Banking portals may block or challenge users because the IP appears to come from another country.
  • Streaming platforms may show the wrong content library or deny access.
  • Fraud prevention systems may flag legitimate sessions as suspicious.
  • Ad platforms and analytics tools may misclassify traffic.
  • Compliance-sensitive services may apply the wrong regional rules.
  • Support teams may receive complaints that are difficult to diagnose.

The problem becomes more visible in the IPv4 secondary market because prefixes move more often. A block that was previously routed in one region may later be leased to a customer in another region, transferred to a new holder or used by a different infrastructure provider.

For example, a company may lease a /24 for infrastructure in Germany, but parts of the internet may still classify the range as being located in another country. From the customer’s point of view, the service may look broken even though the routing is technically correct.

Why geolocation matters for IPv4 leasing and acquisition

Geolocation accuracy is especially important when IPv4 space is leased, purchased or transferred from another organization. The new user may receive valid technical documentation, but the wider internet may still associate the prefix with its previous location, previous routing history or previous abuse patterns.

This creates a gap between legal control and operational readiness. A company may be fully authorized to use a block, but still face problems with incorrect geolocation, DNSBL listings, outdated route objects, missing ROAs or poor reputation signals.

For IPv4 lessees

A leased prefix should be checked before customer traffic starts. Price matters, but routing readiness, geolocation accuracy and reputation history often matter more in production.

For IPv4 buyers

A purchased block can become a long-term asset, but only if the buyer understands its previous use, abuse history, registry status and operational condition.

For resource holders

Owners leasing out unused IPv4 space should keep documentation, route authorization and abuse handling clean to protect long-term asset value.

For businesses that depend on stable infrastructure, these issues can affect more than network configuration. They can influence customer access, email deliverability, fraud checks, compliance reviews and support workload.

Geofeeds: a practical way to reduce geolocation mismatch

A geofeed is a standardized CSV file that maps IP prefixes to geographic information such as country, region and city. The format is described in RFC 8805.

Instead of forcing every geolocation provider to infer location indirectly, a geofeed lets a network operator publish a structured declaration of where prefixes should be geolocated.

Example geofeed entry

203.0.113.0/24,DE,DE-BE,Berlin,

The exact data should match the operational reality of the network. For privacy and accuracy reasons, geofeeds should describe infrastructure or user groups at an appropriate level, not expose overly precise information about individual users.

Benefits of publishing a geofeed

Faster correction

Geolocation providers receive a clear and structured source instead of relying only on inference.

Lower support cost

Fewer users are blocked or misclassified because of stale location data.

Better operational control

The resource holder can maintain location data as prefixes are reassigned.

Cleaner onboarding

Newly leased, transferred or acquired IPv4 space can be prepared before production traffic begins.

For operators managing many IPv4 ranges, geofeeds should be part of the normal provisioning workflow. Whenever a prefix is leased, moved, transferred or reassigned, the geofeed should be reviewed and updated.

Signed geofeeds and RPKI

Publishing a geofeed is useful, but consumers also need to know that the file is legitimate. RFC 9632 describes how geofeed data can be discovered and how it can optionally be authenticated using RPKI.

A signed geofeed helps prove that the location information was published by the legitimate resource holder or an authorized party. This matters because incorrect geolocation data can affect access control, fraud systems, digital services and user trust.

Important: RPKI does not define IP geolocation by itself. RPKI helps validate routing authorization. Signed geofeeds use resource ownership signals to make geolocation data more verifiable.

Signed geofeeds are especially relevant for IPv4 leasing providers, hosting operators, networks with frequent customer reallocations and companies operating infrastructure across several countries.

Geofeeds do not guarantee instant correction across every provider. Each geolocation database has its own update process. Still, publishing a correct geofeed gives providers a clear, machine-readable source and reduces the time spent on manual correction requests.

For companies that lease or buy IPv4 resources, geofeeds should be combined with routing security. InterLIR explains the practical role of RPKI in IPv4 leasing and BGP security in its article What Is RPKI and Why It Matters for IPv4 Leasing, BYOIP, and BGP Security.

Acquired IPv4 reputation, blacklisting and reputation debt

Geolocation is only one side of the problem. The second hidden cost is IP reputation debt.

IP reputation debt means the negative operational history attached to an IP range before the new owner or lessee starts using it. This can include spam, phishing, malware hosting, botnet activity, bulletproof hosting, scanning, abusive proxy activity or previous route hijacking incidents.

DNS-based blocklists and reputation systems track IP addresses and ranges associated with abuse. When an IPv4 block changes hands, its legal or commercial ownership may change, but reputation systems may still remember the previous behavior. A clean transfer document does not automatically erase blacklist history.

Email deliverability

Messages may be rejected, throttled or routed to spam.

Network access

Firewalls and security platforms may block or challenge traffic.

Customer trust

Users may see warnings, failed logins or unusual verification prompts.

Operational delays

Delisting and remediation may take days or weeks.

Not every listing has the same meaning. Some lists indicate direct abuse. Others are policy-based, for example dynamic residential ranges that should not send mail directly. Some listings expire automatically after the activity stops, while others require manual delisting and evidence of remediation.

This is why reputation checks should be done before purchase, lease or production onboarding.

Why acquired IPv4 reputation can be riskier than expected

Transferred or leased IPv4 space should never be assumed clean without verification. The risk varies by prefix, region, previous user and intended use case, but the operational lesson is simple: a block’s past can affect its future value.

Why the risk exists

  1. Previous abuse may not be visible in basic WHOIS checks. A block can look valid in registry data while still having a poor reputation.
  2. Bad actors may try to reset reputation through new address space. Abusive operators often move between ranges after older prefixes become burned.
  3. Reputation systems lag behind ownership changes. Filters may continue to associate the range with the previous user.
  4. Inactive blocks can be abused after reactivation. A prefix that was quiet for months may attract attention when it suddenly starts sending traffic again.
  5. Routing and registry data may not align perfectly. Route objects, ROAs, origin ASNs and WHOIS records may require cleanup after transfer or lease activation.

For IPv4 buyers and lessees, this means that price per IP is only one part of the real cost. A cheaper block can become expensive if it requires urgent delisting, repeated geolocation correction, customer support escalation or onboarding delays.

Due diligence checklist before acquiring or leasing IPv4

The best time to identify hidden IPv4 costs is before the block is used in production. A structured due diligence process should cover ownership, authorization, routing, geolocation and abuse history.

1. Verify ownership and authorization

  • Check WHOIS and RDAP records.
  • Confirm organization and maintainer details.
  • Review the chain of title for transferred resources.
  • Obtain a proper Letter of Authorization where needed.
  • Confirm that the lessor, seller or marketplace is authorized to provide the range.

2. Check routing hygiene

  • Confirm the intended origin ASN.
  • Create or update RPKI ROAs before production announcement.
  • Review maxLength settings to avoid accidental RPKI-invalid announcements.
  • Check IRR route objects and remove outdated routing records where possible.
  • Monitor BGP visibility after the prefix goes live.

3. Audit IP reputation

  • Check major DNSBLs and security reputation services.
  • Review historical abuse indicators where available.
  • Check whether the range was associated with spam, malware, phishing or proxy abuse.
  • Test email deliverability before assigning the range to mail infrastructure.
  • Document all findings before accepting the block for production use.

4. Audit geolocation

  • Compare the prefix across multiple geolocation providers.
  • Identify incorrect country, region or city data.
  • Publish or update a geofeed before customer traffic starts.
  • Add the geofeed reference in WHOIS or RDAP where supported.
  • Submit corrections directly to key geolocation providers when needed.

5. Prepare DNS and email foundations

  • Configure reverse DNS where applicable.
  • Set SPF, DKIM and DMARC for domains that will send mail.
  • Avoid using newly acquired space for high-volume email immediately.
  • Warm up email traffic gradually and monitor bounce patterns.
  • Keep abuse contact information accurate and responsive.

6. Use a staged production rollout

  • Start with low-risk services before critical workloads.
  • Monitor logs for blocked traffic, login challenges and user complaints.
  • Track blacklist status during the first weeks.
  • Keep a rollback plan ready if the range causes service disruption.
  • Allow time for geolocation and reputation corrections to propagate.

How InterLIR helps reduce hidden IPv4 costs

InterLIR helps make IPv4 resources usable, not just available

InterLIR is an IPv4 marketplace for companies that need to lease, buy, sell or monetize IPv4 resources. But the value of an IPv4 block is not limited to its price or availability. The block also needs to be operationally ready.

That means checking authorization, routing records, geolocation consistency and reputation risks before the prefix is used in production.

For companies leasing or acquiring IPv4 space, InterLIR helps reduce the operational friction that often appears after the transaction:

IPv4 leasing and marketplace access

Companies can access available IPv4 blocks through a structured marketplace model instead of relying on informal or poorly documented arrangements.

Authorization and documentation

Proper LOA handling, WHOIS/RDAP checks and resource-holder verification help reduce onboarding delays and ownership confusion.

Routing readiness

Route objects, RPKI/ROA and origin ASN checks help ensure the prefix is technically ready for announcement.

Geolocation support

Geolocation review and correction workflows help reduce wrong-country classification and related customer-facing issues.

Reputation awareness

Blacklist and abuse-history awareness helps customers avoid assigning problematic address space to sensitive workloads too quickly.

Operational continuity

A more structured IPv4 process reduces the chance that hidden issues appear only after production traffic starts.

For companies that need IPv4 space quickly, InterLIR IPv4 leasing provides access to available IPv4 blocks through a marketplace model. For IP resource holders, leasing out IPv4 addresses through InterLIR can turn unused IPv4 space into recurring revenue while keeping the process organized.

If an acquired or leased prefix will later be used in a cloud environment, InterLIR BYOIP can also help with IP-side preparation. However, BYOIP is only one possible use case. The broader issue is making sure the IPv4 block is clean, authorized, correctly routed and ready for real infrastructure.

How to prepare acquired IPv4 before production use

Before a leased or purchased IPv4 block is assigned to customers, applications or production infrastructure, operators should verify that the prefix is ready from several angles.

Preparation step Why it matters What to check
Authorization Confirms that the announcing party is allowed to use the prefix. LOA, resource holder, lessor or seller, registry records.
Routing Prevents invalid announcements and routing conflicts. Origin ASN, RPKI ROA, IRR route objects, BGP visibility.
Geolocation Reduces wrong-country classification and service disruption. Major geolocation providers, geofeed, WHOIS/RDAP references.
Reputation Protects email, access control and customer-facing services. DNSBL status, abuse history, mail reputation, traffic patterns.
Rollout Limits the impact if a hidden issue appears. Low-risk testing, monitoring, rollback plan, support readiness.

FAQ: acquired IPv4, geolocation and blacklists

What is IPv4 reputation debt?

IPv4 reputation debt is the negative history attached to an IP range before a new owner or lessee starts using it. It may include spam, malware, phishing, proxy abuse, scanning, botnet activity or previous blacklist listings.

Can a geofeed instantly fix incorrect IP geolocation?

No. A geofeed gives geolocation providers a structured source of information, but each provider updates its database on its own schedule. A geofeed reduces uncertainty and manual work, but it does not guarantee instant global correction.

Does RPKI fix IP geolocation?

No. RPKI helps validate whether an ASN is authorized to originate a prefix. It improves routing security. Geolocation is handled separately through geolocation databases, geofeeds and provider correction processes.

Should acquired IPv4 be used for email immediately?

Usually not. Email is highly sensitive to IP reputation. Before using acquired IPv4 for mail, check DNSBLs, configure reverse DNS, set SPF, DKIM and DMARC, test deliverability and warm up sending volume gradually.

Why is InterLIR relevant to this topic?

InterLIR works with IPv4 leasing, buying, selling and operational preparation of IPv4 resources. These are exactly the scenarios where hidden IPv4 costs appear: geolocation mismatch, blacklist exposure, routing inconsistencies and reputation debt.

Conclusion

IPv4 scarcity has turned address blocks into valuable assets, but acquired IPv4 space can carry hidden operational costs.

Geolocation mismatch can break user access, trigger fraud systems and generate support tickets. Reputation debt can damage email deliverability, network access and customer trust. Routing inconsistencies can create additional risk if RPKI, IRR and WHOIS records are not updated correctly.

The solution is not to avoid the IPv4 market. The solution is to treat IPv4 acquisition as an operational risk process, not only a commercial transaction.

Before using purchased or leased IPv4 space, verify ownership, audit reputation, publish geofeeds, configure RPKI/ROA and plan a staged rollout. With proper preparation, acquired IPv4 can become a reliable infrastructure asset instead of a source of preventable problems.

Need IPv4 space without hidden operational surprises?

InterLIR helps companies lease, buy and prepare IPv4 resources with attention to authorization, routing, geolocation and reputation risks.

Lease IPv4 addresses
Talk to InterLIR

Related InterLIR resources

Rent IPv4 Addresses with InterLIR
Lease Out IPv4 Addresses
What Is RPKI and Why It Matters
InterLIR BYOIP

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

Test Post Created by Puppeteer

Posted on by lir_auto

This is a test post created using automation with Puppeteer. It demonstrates the process of logging into WordPress, navigating to the post creation page, filling in a title and content, and publishing the post.

This workflow can be fully automated using Puppeteer, a Node.js library that provides a high-level API to control Chrome over the DevTools Protocol.

Cookie Consent with Real Cookie Banner Privacy settings