How to Prevent IPv4 Hijacking During a Transfer: 10 Security Steps

Transferring IPv4 address space is not only a commercial and registry process. It is also a sensitive routing operation.

During an IPv4 transfer, control of a prefix moves from one organization to another. Registry records, Route Origin Authorizations, Internet Routing Registry objects, upstream-provider filters, reverse DNS settings, and live BGP announcements may all need to change.

When these changes are completed in the wrong order—or when identity and authorization checks are weak—the address block can become unreachable, incorrectly announced, or exposed to an IPv4 hijacking attempt.

Organizations that plan to buy IPv4 addresses or sell IPv4 addresses should therefore treat routing security as a core part of the transaction, not as a post-transfer administrative task.

This guide explains how buyers, sellers, brokers, hosting providers, data centers, and network operators can prevent IPv4 hijacking during a transfer.

What Is IPv4 Hijacking?

IPv4 hijacking, commonly called BGP prefix hijacking, occurs when an Autonomous System announces an IPv4 prefix that it is not legitimately authorized to originate.

The Border Gateway Protocol, or BGP, is used by autonomous networks to exchange Internet reachability information. However, traditional BGP does not independently prove that the organization announcing a prefix is the legitimate resource holder. RPKI-based origin validation was developed to help networks verify whether an origin ASN is authorized to announce a particular prefix.

A hijacked route can cause Internet traffic to be:

• Redirected to an unauthorized network
• Intercepted or inspected
• Dropped, creating an outage
• Used for impersonation, spam, fraud, or other abuse
• Divided between the legitimate and unauthorized networks

Some incidents are deliberate attacks. Others result from configuration errors, stale routing records, incorrect prefix lengths, or a former holder continuing to announce transferred space.

For the affected organization, the practical outcome may be the same: instability, lost traffic, damaged IP reputation, and customer disruption.

Why Is an IPv4 Transfer a Sensitive Routing Period?

An IPv4 transfer changes administrative control, but the global routing system does not automatically update every associated routing authorization, filter, and operational record at the same moment.

For example, the seller may still have an old ROA or IRR route object associated with the block. The buyer’s upstream provider may not yet have updated its prefix filters. The buyer may announce the block before its new ROA becomes visible to validators.

This creates a temporary mismatch between:

• The registered resource holder
• The authorized origin ASN
• The ASN visible in BGP
• The information published in an IRR
• The prefix filters used by upstream providers
• The organization shown in operational contact records

ARIN specifically advises transfer sources to review affected ROAs and IRR records before a transfer. After completion, the recipient is responsible for creating or updating its ROAs, authoritative IRR entries, and reverse DNS settings.

A secure transfer process must therefore coordinate both the registry layer and the routing layer.

1. Verify the Registered IPv4 Holder

Before signing an agreement, sending funds, or submitting a provider Letter of Authorization, verify that the seller has the authority to transfer the address block.

Review the relevant Regional Internet Registry’s records and confirm:

• The registered organization
• The exact IPv4 prefix and prefix length
• The organization identifier or registry account
• The administrative and technical contacts
• The resource’s transfer eligibility
• Whether the block is involved in a dispute
• Whether additional parties must authorize the transaction

For ARIN transfers, the source must be the current registered holder and must not be involved in a dispute concerning the resource. Transfer requests must also come from an account connected to an authorized point of contact for the organization.

Registry data should be checked directly. Screenshots, forwarded emails, invoices, and privately created ownership documents should not be treated as substitutes for registry verification.

For higher-risk or legacy resources, organizations should also examine the chain of authority, historical registration documents, corporate changes, and the identity of the individuals approving the transfer.

2. Create a Written Transfer and Routing Runbook

A secure IPv4 transfer should have a documented sequence of actions.

The runbook should identify:

• The seller’s technical and registry contacts
• The buyer’s technical and registry contacts
• The old origin ASN
• The intended new origin ASN
• The exact prefixes that will be announced
• The planned ROA configuration
• Required IRR changes
• Upstream-provider approval requirements
• The BGP withdrawal and announcement sequence
• Monitoring tools and escalation contacts
• Rollback conditions
• Evidence required before funds are released

Every action should have a named owner and a completion status.

Avoid vague instructions such as “update routing after approval.” Specify which party will update each object, when the change will happen, how it will be verified, and what must occur before the next step begins.

3. Record the Pre-Transfer Routing Baseline

Before changing anything, record the existing state of the address block.

The baseline should include:

• Current BGP origin ASN
• Visible AS paths
• Existing ROA status
• ROA prefix and maximum-length values
• Existing IRR route objects
• WHOIS or RDAP registration data
• Reverse DNS delegations
• Route visibility across multiple regions
• Current upstream and peering relationships
• Blacklist and abuse-reputation status
• Known subprefix announcements

This provides evidence of the block’s condition before the transfer and makes unauthorized changes easier to identify.

Do not rely on a single route collector or monitoring platform. A prefix may appear normal from one region while being incorrectly announced or partially hijacked elsewhere.

4. Review and Remove the Seller’s Old ROAs

A Route Origin Authorization, or ROA, specifies which ASN is authorized to originate an IP prefix. It can also define the maximum prefix length that the ASN is allowed to announce.

Old ROAs must be handled carefully during a transfer.

Under ARIN’s published guidance, a source organization should confirm that transferring resources are not included in active ROAs before submitting the transfer. A prefix in a multiprefix ROA should be removed from that ROA, while a single-prefix ROA is removed automatically when the transfer occurs.

The exact procedure may vary by RIR and resource type, so both parties should follow the applicable registry’s current instructions.

Failure to address an old ROA can lead to:

• A valid announcement becoming RPKI invalid
• The former ASN remaining authorized longer than intended
• Conflicting routing intent
• Delays in creating the recipient’s new authorization
• Reachability problems on networks that reject RPKI-invalid routes

The seller should not simply delete every routing object without coordination. Removing authorization too early may disrupt a legitimate transition announcement. The timing must be agreed upon by the seller, buyer, RIR, and relevant network providers.

5. Create a Precise ROA for the New Origin ASN

After the recipient has the registry authority required to manage RPKI for the resource, it should create a ROA matching the intended production announcement.

The ROA should specify:

• The correct IPv4 prefix
• The correct new origin ASN
• The narrowest operationally appropriate maximum length
• Only the announcements that the buyer genuinely intends to originate

Avoid setting an unnecessarily broad maxLength.

For example, authorizing a /24 maximum length for a much larger aggregate may permit numerous more-specific routes to appear RPKI valid. Current RPKI best-practice guidance recommends configuring a maximum length that covers the prefixes actually announced—and nothing more. Overly liberal values can increase exposure to forged-origin subprefix hijacking.

After creating the ROA, verify that:

1. It has been published.
2. The prefix-origin pair is shown as valid.
3. The intended BGP announcement will not be classified as invalid.
4. No unrelated announcements have been unintentionally authorized.

Do not assume that clicking “create” means every relying party has immediately received the updated record. Confirm the published result with independent validation and routing-monitoring tools before relying on it operationally.

6. Update IRR Route Objects and Provider Filters

Internet Routing Registries allow network operators to document intended routing information. A route object associates an IPv4 prefix with the ASN expected to originate it. Network providers frequently use IRR data to generate customer prefix filters.

Before the transfer, the seller should review route objects that reference the transferred prefix and remove or update records that will no longer apply.

After the transfer, the buyer should publish authoritative route objects for the new origin ASN.

The buyer should then confirm that each upstream provider has regenerated or manually updated its filters. Otherwise, the new announcement may be rejected even when the registry transfer and ROA are correct.

Check all relevant systems, including:

• RIR-operated routing registries
• RADB or other mirrored IRRs
• Provider-specific customer portals
• AS-SET objects
• Prefix lists
• Maximum-prefix limits
• Route-server authorization
• Peering configuration

RPKI and IRR are complementary controls. RPKI provides cryptographically verifiable origin authorization, while IRR records continue to be used by many networks to construct routing policies and filters.

7. Strengthen LOA and Provider-Onboarding Verification

A Letter of Authorization is often used to show that a network is permitted to originate a prefix. However, an LOA is only as reliable as the identity-verification process behind it.

Attackers may submit forged documents, impersonate authorized staff, compromise email accounts, or exploit weak provider-onboarding processes.

An APNIC case study published in 2026 described how social engineering and weaknesses in provider onboarding contributed to unauthorized routing activity despite the availability of routing-security tools. The case highlights that cryptographic controls must be combined with strong identity checks and operational coordination.

Providers should verify authorization through multiple channels:

• Match the organization against current RIR records.
• Contact a known registry-listed or contract-listed representative.
• Use an out-of-band callback for sensitive changes.
• Confirm the prefix and ASN independently.
• Verify corporate domains and email headers.
• Require approval from more than one authorized person.
• Check that the signatory has authority to approve routing.
• Reject documents containing unexplained edits or mismatched details.
• Record who approved the request and when.
• Revalidate authorization after the registry transfer is complete.

An emailed PDF alone should not be sufficient authorization for a high-value IPv4 block.

8. Require Strict Prefix-Level Filtering

Upstream providers should allow customers to announce only prefixes and ASNs they are legitimately authorized to originate.

MANRS recommends explicit prefix-level filtering or equivalent controls for customer routes. It also notes that AS-path filtering alone is not sufficient to prevent serious routing problems.

For a transferred IPv4 block, the provider should configure filters that match:

• The exact authorized prefix
• The approved origin ASN
• The permitted prefix lengths
• The expected customer session
• Any approved downstream relationships

The provider should reject:

• Unauthorized more-specific announcements
• Announcements from an unexpected ASN
• Prefixes not included in the customer authorization
• RPKI-invalid routes, in accordance with its published routing policy
• Routes received through an unauthorized session

Buyers should ask prospective upstream providers how they validate customer resources and how quickly filters can be updated during a transfer.

9. Coordinate the BGP Cutover

The live routing cutover should take place only after the registry and authorization prerequisites have been confirmed.

A controlled sequence may include:

1. Confirming that the registry transfer is complete.
2. Confirming that the recipient can manage the resource.
3. Publishing and validating the recipient’s ROA.
4. Publishing the new IRR route object.
5. Confirming that upstream filters have been updated.
6. Withdrawing the seller’s old announcement.
7. Announcing the prefix from the approved new ASN.
8. Monitoring route propagation and RPKI status.
9. Confirming reachability from several networks and regions.
10. Closing old sessions and access paths after stability is established.

Avoid extended, unexplained simultaneous announcements from the old and new origin ASNs. Although controlled multi-origin routing can be legitimate, it can also make anomalies harder to distinguish from unauthorized activity.

Any overlap should have a documented reason, limited duration, explicit authorization, and active monitoring.

10. Monitor the Prefix Before, During, and After Transfer

Routing monitoring should begin before the cutover and continue after the transaction is commercially complete.

Configure alerts for:

• A new or unexpected origin ASN
• RPKI-invalid status
• A change from valid to not found
• More-specific prefix announcements
• Unusual AS-path changes
• Loss of global visibility
• Sudden regional reachability differences
• Unauthorized IRR modifications
• Changes to registry contacts
• Unexpected reverse DNS changes
• New abuse or blacklist listings

Keep current NOC, technical, and abuse contacts in the appropriate registry and network databases. MANRS recommends maintaining operational contact details so other network operators can quickly coordinate during a routing incident.

A monitoring alert is useful only when someone is responsible for responding to it. Define who will investigate, who can contact providers, who can change ROAs, and who has authority to initiate a rollback.

What RPKI Can—and Cannot—Prevent

RPKI is one of the most important defenses against IPv4 origin hijacking, but it is not a complete BGP-security solution.

A valid ROA allows networks performing Route Origin Validation to determine whether the originating ASN is authorized for the prefix. This can help prevent an unauthorized origin announcement from being accepted and propagated.

However, RPKI origin validation does not independently validate the entire AS path. BGPsec was designed to supplement origin validation by adding protection for BGP path information, although deployment and operational support differ across networks.

RPKI also cannot compensate for:

• A compromised authorized ASN
• An overly broad ROA maximum length
• Incorrect ROA configuration
• Weak provider identity verification
• Compromised registry credentials
• Social-engineering attacks
• Failure by networks to enforce Route Origin Validation
• Internal routing or access-control failures

The strongest defense is layered: registry verification, RPKI, IRR accuracy, provider filtering, secure onboarding, controlled BGP changes, credential security, and continuous monitoring.

Common IPv4 Transfer Security Mistakes

Announcing the Prefix Before the ROA Is Ready

The new route may become RPKI invalid and be rejected by networks enforcing origin validation.

Leaving Old IRR Objects Active

Providers may continue building filters from incorrect or outdated routing information.

Using an Overly Broad Maximum Length

This can authorize more-specific announcements that are not operationally required.

Trusting an LOA Without Independent Verification

A professional-looking document does not prove that the sender controls the resource.

Releasing Funds Before Registry Completion

Payment milestones should be linked to objective transfer conditions, not only emails or screenshots.

Failing to Confirm Upstream Filters

A correct ROA does not guarantee that a provider’s customer prefix list has been updated.

Monitoring from Only One Location

Partial or regional hijacks may not be visible from every route collector.

Keeping Former Staff and Vendors Authorized

Old registry accounts, API keys, email accounts, provider portals, and RPKI access should be removed during the final handover.

IPv4 Transfer Security Checklist

Before the Transfer

• Verify the registered holder directly with the applicable RIR.
• Confirm the exact prefixes and intended recipient.
• Review transfer eligibility and any disputes.
• Record current BGP, RPKI, IRR, registry, rDNS, and reputation data.
• Identify the old and new origin ASNs.
• Agree on the routing cutover plan.
• Review the seller’s ROAs and IRR objects.
• Obtain upstream-provider requirements.
• Establish escrow and registry-based release conditions.
• Confirm incident and escalation contacts.

During the Transfer

• Monitor registry-record changes.
• Protect registry accounts with strong authentication.
• Validate communications through known contacts.
• Do not approve unexpected ASN or prefix changes.
• Confirm the registry transfer before the production cutover.
• Create the recipient’s precise ROA.
• Verify the published RPKI state.
• Publish authoritative IRR records.
• Confirm upstream filters have been updated.
• Coordinate withdrawal and announcement timing.

After the Transfer

• Confirm the prefix is originated only by the intended ASN.
• Verify RPKI-valid status.
• Test global and regional reachability.
• Remove obsolete ROAs and IRR records.
• Update reverse DNS delegations.
• Update NOC and abuse contacts.
• Revoke seller and former-provider access.
• Archive transfer and routing evidence.
• Keep route-change alerts active.
• Conduct a post-transfer security review.

How i.lease Supports a More Secure IPv4 Transfer

The safest IPv4 transactions combine commercial controls with registry compliance and operational readiness.

The i.lease marketplace provides a structured process for organizations seeking to acquire IPv4 address space. Its published buying workflow includes ownership and reputation screening, escrow protection, RIR-aligned documentation, coordinated registry transfers, and an operational handover covering RPKI, reverse DNS, and routing configuration.

For buyers, this helps reduce the risks associated with unknown counterparties, incomplete documentation, and poorly coordinated routing changes.

For sellers, a structured process helps establish a clear chain of custody and ensures that obsolete routing authorizations are addressed as the resource moves to its new holder.

Explore verified IPv4 blocks on the i.lease marketplace or list unused IPv4 address space for sale.

Frequently Asked Questions

Can RPKI completely prevent IPv4 hijacking?

No. RPKI can validate whether an ASN is authorized to originate a prefix, which makes it an important defense against origin hijacking. It does not validate every part of the BGP path and cannot replace provider filtering, identity checks, credential security, or route monitoring.

When should the buyer create the new ROA?

The buyer should create the new ROA after obtaining the registry authority required to manage RPKI for the transferred resource and before depending on the new production announcement. The exact sequence should follow the relevant RIR’s procedures.

What happens if the old ROA is not removed?

An old or conflicting ROA may cause the new announcement to become invalid, preserve outdated authorization, or create routing confusion. Sellers and buyers should review ROAs as part of the formal transfer runbook.

Is an LOA enough to authorize a BGP announcement?

An LOA can support the authorization process, but it should not be accepted without independent identity and registry verification. Providers should confirm the resource holder, signatory authority, prefix, ASN, and transfer status through trusted channels.

Why are IRR records important when RPKI is available?

Many network operators use IRR data to create prefix filters. An accurate ROA may not prevent reachability problems when a provider’s IRR-derived filters still reference the old origin ASN.

How long should an IPv4 prefix be monitored after a transfer?

There is no universal monitoring period. At minimum, active monitoring should continue throughout the transfer, cutover, and stabilization period. Long-term route-origin, RPKI-status, and more-specific-announcement alerts provide stronger protection.

Conclusion

Preventing IPv4 hijacking during a transfer requires more than updating the name of the registered resource holder.

The seller must remove obsolete authorizations. The buyer must publish accurate routing intent. Upstream providers must verify the customer and update their filters. Both parties must coordinate the BGP cutover and monitor the prefix from multiple locations.

The essential controls are:

• Verified registry authority
• Precise RPKI ROAs
• Accurate IRR route objects
• Strong LOA and identity validation
• Strict provider prefix filtering
• Coordinated BGP withdrawals and announcements
• Continuous route monitoring
• Complete post-transfer access cleanup

When these controls are built into the transaction from the beginning, organizations can reduce the risk of hijacking, outages, routing invalids, and delayed deployment.

Secure your next IPv4 transaction with a structured, RIR-aligned process. Start buying verified IPv4 address space through i.lease.

Frequent Asked Questions