Leasing an IPv4 or IPv6 prefix gives a customer the right to use that address space under the terms of the lease. It does not automatically give the customer control of the RPKI authority attached to the prefix.

That distinction matters once the leased block is announced through BGP.

For a leased prefix to pass Route Origin Validation, the BGP announcement needs to match the authorization published through RPKI. The prefix, origin ASN, and permitted prefix length must agree with an applicable Route Origin Authorization, or ROA.

In a typical IP leasing deployment, the workflow looks like this:

IP resource holder → leased prefix → origin ASN decision → ROA → IRR/LOA → BGP announcement → Route Origin Validation → external monitoring

If any part of that chain is wrong, a valid commercial lease can still produce an RPKI-invalid route.

RPKI for IP Leasing at a Glance

RPKI provides a cryptographically verifiable way for an address holder to state which Autonomous System may originate a route for its address space.

A ROA is a digitally signed object that allows an address-space holder to authorize an AS to originate one or more prefixes.

For leased address space, several parties may be involved.

Component	Main Role
IP resource holder	Holds or controls authority over the address resource
Lessee	Uses the leased IPv4 or IPv6 block
Origin ASN	ASN that originates the prefix into BGP
ROA	Authorizes the origin ASN for the prefix
BGP	Carries the route announcement
Route Origin Validation	Compares the BGP origin with RPKI data
IRR	Publishes routing-policy information
LOA	Documents operational permission where required
RIR	Maintains resource registration and RPKI services

The central rule is simple:

The ROA needs to authorize the ASN that actually originates the leased prefix in BGP.

What Is RPKI?

Resource Public Key Infrastructure, or RPKI, is a routing-security system built around cryptographically signed resource information.

Its purpose is to let network operators answer a specific question:

Is this ASN authorized by the address holder to originate this prefix?

Network operators can use RPKI data to compare the origin ASN in a BGP route against the authorization published for that address space.

RPKI deals with route origin.

It does not:

• encrypt traffic
• verify every AS in the AS_PATH
• replace a firewall
• protect an application from DDoS attacks
• determine IP reputation
• replace normal BGP policy

Current RPKI deployment primarily checks the relationship between a prefix and its origin ASN.

What Is a Route Origin Authorization?

A Route Origin Authorization is a signed RPKI object that states which ASN may originate specified IP prefixes.

A basic ROA contains three routing concepts operators need to understand.

Prefix

The IPv4 or IPv6 network being authorized.

Origin ASN

The Autonomous System permitted to originate that route.

Maximum permitted prefix length

An optional value that can permit more-specific routes.

A simple example might look conceptually like:

Prefix:       203.0.113.0/24

Origin ASN:   AS64500

If AS64500 announces exactly 203.0.113.0/24, the announcement can match this authorization.

If several ASNs need permission to originate the same address space, separate ROAs can be used for those ASNs.

How RPKI Works With Leased IP Space

IP leasing separates operational use from resource ownership.

A business may lease:

203.0.113.0/24

and use that block for:

• Serveurs dédiés
• colocation infrastructure
• VPS platforms
• proxy infrastructure
• VPN infrastructure
• multi-site hosting
• customer networks

The lessee may operate the servers and BGP session, but the original resource holder may still control the RPKI certificate covering the prefix.

That means the lessee may not be able to create its own ROA directly.

A downstream organization using address space received from another provider may need the upstream resource provider to create the ROA on its behalf.

This distinction is central to leased-address deployments.

Commercial use of an IP block and cryptographic authority over that block are separate responsibilities.

Who Creates the ROA for a Leased Prefix?

The party with RPKI authority over the resource normally creates the ROA, unless an applicable delegated RPKI arrangement gives another organization that authority.

Three operating models are common.

Resource Holder Creates the ROA

This is a straightforward lease model.

The customer provides:

• leased prefix
• intended origin ASN
• planned announcement length
• required routing date

The resource holder creates the matching ROA.

RPKI Authority Is Delegated

Some organizations operate delegated RPKI systems.

The technical model depends on the RIR, certificate hierarchy, resource status, and operating arrangement.

This setup gives the delegated party more control, but it also adds certificate and repository responsibilities.

Provider Manages the Routing Arrangement

A customer may lease IP addresses without running a public ASN.

The hosting or network provider can originate the leased prefix from its own ASN where the commercial and routing arrangement permits it.

The ROA should then authorize the provider ASN.

Customer ASN vs Provider ASN

The correct ASN in a ROA is determined by the actual BGP origin.

Routing Model	BGP Origin	ROA Should Authorize
Customer originates route	Customer ASN	Customer ASN
Provider originates route	Provider ASN	Provider ASN
BYOIP platform originates route	Platform-designated ASN	Required platform ASN
Planned multi-origin design	Several ASNs	Appropriate authorization for each ASN

Customer ASN Model

A customer ASN makes sense when the customer controls its own routing.

Common use cases include:

• multihoming
• colocation
• independent routing
• multi-provider BGP
• several deployment locations

The customer should coordinate the route announcement with the address provider so the ROA authorizes the customer ASN.

Provider ASN Model

A customer does not need a public ASN for every leased-IP deployment.

If the hosting provider originates the block, the ROA should authorize the provider’s ASN.

This arrangement is common when the customer uses the leased prefix but does not operate its own BGP routing policy.

ROA Prefix Length and maxLength

maxLength is one of the most common sources of RPKI configuration errors.

Suppose a ROA contains:

Prefix:       203.0.113.0/24

Origin:       AS64500

and the network announces:

203.0.113.0/24

That is a straightforward match.

Now assume the network later announces:

203.0.113.0/25

The ASN may still be correct, but the /25 can become Invalid if the ROA does not permit a prefix that specific.

Avoid Unnecessary maxLength Values

The safer approach is to keep ROA authorization aligned with the prefixes that are actually expected in BGP.

If the network will only announce:

203.0.113.0/24

there may be no operational reason to authorize /25, /26, /27, or other more-specific routes.

This reduces the number of routes that can be originated while still matching the authorization.

For stable routing, ROA design should match the real BGP announcement plan.

Simple Example

ROA:

203.0.113.0/24

Origin AS64500

BGP:

203.0.113.0/24

Origin AS64500

Result:

Valid

If the same ROA does not allow /25 and BGP announces:

203.0.113.0/25

Origin AS64500

the more-specific route can become:

Invalid due to prefix length

RPKI Valid, Invalid, and NotFound

A BGP announcement can receive different validation states after comparison with RPKI data.

Terminology differs slightly across routing software and tools. You may see Valid, Invalid, and either NotFound ou alors Unknown.

State	Meaning
Valid	An applicable ROA authorizes the origin ASN and prefix length
Invalid	A covering ROA exists, but the ASN or prefix length conflicts with it
NotFound / Unknown	No applicable ROA covers the route

Valid

Example:

ROA:

203.0.113.0/24

AS64500

 

BGP:

203.0.113.0/24

Origin AS64500

The prefix and origin ASN agree with the authorization.

Invalid Because of Origin ASN

Example:

ROA:

203.0.113.0/24

AS64500

 

BGP:

203.0.113.0/24

Origin AS64501

The address range is covered, but the origin AS does not match.

Invalid Because of Prefix Length

The ASN may match, but a route can still fail validation if it is more specific than the applicable ROA permits.

Example:

ROA:

203.0.113.0/24

Origin AS64500

No authorization for /25

 

BGP:

203.0.113.0/25

Origin AS64500

Result:

Invalid because of prefix length

NotFound Is Not the Same as Invalid

NotFound or Unknown means no applicable ROA covers the route.

That is different from an announcement actively conflicting with a published authorization.

RPKI produces route-origin validation information. Network operators then decide how their routing policies handle the result.

LOA vs IRR Route Object vs ROA

LOA, IRR, and ROA are often discussed together during IP leasing, but they solve different problems.

Item	Main Purpose	Cryptographic RPKI Authorization
LOA	Documents operational permission	Non
IRR route object	Publishes routing-policy information	Non
ROA	Authorizes the BGP origin through RPKI	Oui

LOA

A Letter of Authorization documents permission between organizations.

A hosting company or transit provider may request one before accepting an announcement.

An LOA does not make an RPKI-invalid route Valid.

IRR Route Object

Internet Routing Registry records publish routing-policy data.

For IPv4 this commonly uses a route object.

For IPv6 it commonly uses a route6 object.

Many network operators still use IRR data to build route filters.

ROA

A ROA provides cryptographically verifiable route-origin authorization through RPKI.

A production IP leasing arrangement may use all three:

LOA for operational permission

IRR for routing-policy registration

ROA for cryptographic origin authorization

They are not interchangeable.

Practical Authorization and BGP Workflow

A leased prefix should move through a controlled deployment sequence.

1. Confirm the exact IPv4 or IPv6 prefix.
2. Confirm the resource holder.
3. Identify who controls RPKI.
4. Decide which ASN will originate the route.
5. Confirm the exact BGP announcement lengths.
6. Prepare an LOA where required.
7. Create or update the IRR record.
8. Create or update the ROA.
9. Check that the authorization is visible.
10. Configure BGP.
11. Verify route visibility externally.
12. Check the RPKI validation state.
13. Monitor the prefix after launch.

The order matters.

Starting the new BGP announcement before the routing authorization is ready can produce an Invalid route or inconsistent reachability.

IPv4 and IPv6 RPKI Considerations

RPKI works with both IPv4 and IPv6.

IPv4 Leasing

IPv4 leasing often involves:

• /24 and larger public blocks
• customer ASN
• provider ASN
• route filters
• BGP origination
• reverse DNS
• IP reputation
• geolocation

Because IPv4 address space is scarce, address ownership, commercial use, and routing may involve several organizations.

IPv6 Leasing

IPv6 uses a different addressing scale and subnet structure.

A leased IPv6 deployment may involve:

• /48 or larger allocations where applicable
• customer ASN or provider ASN
• route6 IRR objects
• IPv6 BGP
• IPv6 ROAs
• routed subnets

The same RPKI rule still applies:

The live BGP origin and prefix length should match the published authorization.

Prevent Invalid Routes During an ASN Change

Changing the origin ASN without changing RPKI authorization can cause a routing incident.

Suppose a prefix currently originates from:

AS64500

and will move to:

AS64510

Changing BGP first while leaving the old authorization untouched can cause the new route to become Invalid.

A safer sequence is:

Prepare authorization → verify publication → introduce new route → test visibility → withdraw old route → remove authorization no longer required

This sequencing is useful during:

• hosting migrations
• transit changes
• customer ASN deployment
• colocation moves
• BYOIP changes

Treat the ROA as part of the routing change, not as paperwork completed later.

Plan for More-Specific Announcements

Networks may announce more-specific prefixes for:

• traffic engineering
• multi-site routing
• DDoS mitigation
• migration
• regional routing

Those announcements must fit the RPKI policy.

Do not use a broad maxLength simply because more-specific routes might be required one day.

If an aggregate will be split, verify the intended more-specific routes before they are advertised.

For example, if normal operation uses:

203.0.113.0/24

but a planned mitigation service may announce:

203.0.113.0/25

The authorization model needs to account for that routing plan before the mitigation event occurs.

RPKI During Provider Migration

A provider migration can change several routing records at once.

Current design:

Old Provider

     ↓

Old Origin ASN

     ↓

Current ROA

New design:

New Provider

     ↓

New Origin ASN

     ↓

Updated ROA

Do not manage BGP, IRR, and RPKI as unrelated tasks.

Before the cutover, document:

• old origin ASN
• new origin ASN
• active ROA
• required new authorization
• IRR changes
• route activation time
• route withdrawal time
• external visibility tests
• rollback conditions

If two ASNs need to originate the prefix during a planned transition, the RPKI configuration needs to permit that routing model.

Can the Same Prefix Be Authorized for Multiple ASNs?

Yes, where the routing architecture requires it.

Examples include:

• provider migration
• multi-origin routing
• cloud migration
• DDoS mitigation arrangements

A separate ROA can authorize each ASN that needs to originate the same address prefix.

Old authorizations should not remain active without a routing reason.

Every active authorization should map to an actual operating requirement.

RPKI Risks Specific to IP Leasing

Leased prefixes create a responsibility boundary that directly held resources may not have.

Watch for these problems:

1. The lessee assumes it controls the ROA when the resource holder does.
2. The ROA contains the wrong customer or provider ASN.
3. The customer changes ASN without requesting an RPKI update.
4. maxLength is too restrictive for planned more-specific routes.
5. maxLength permits more-specifics that are not required.
6. IRR and RPKI data list different origin ASNs.
7. Authorization remains after the lease has ended.
8. BGP starts before a new ROA is visible.
9. A provider migration begins without confirming route validation.
10. Neither party has clearly accepted responsibility for routing updates.

The right operational question is not only:

Does this prefix have a ROA?

It is:

Does the current ROA authorize the exact route we plan to announce?

Monitor Route Visibility and RPKI Validation

A BGP session showing Established does not prove that a leased prefix has the expected external reachability.

Monitor the route itself.

Track:

• whether the prefix is visible
• observed origin ASN
• RPKI validation state
• actual BGP prefix length
• unexpected more-specific routes
• multiple origins
• route visibility through several networks
• current ROA information

After any ROA change, check active announcements to make sure the expected prefixes remain correctly authorized.

Use Several External Views

Do not rely only on the local router.

Use independent route collectors, looking glasses, RPKI tools, or external probes where appropriate.

A validation tool may show different error classes such as:

• Valid
• Invalid ASN
• Invalid prefix length
• Unknown or NotFound

That distinction helps identify whether the problem comes from the origin ASN or the prefix length.

RPKI Deployment Workflow for Leased IP Space

A repeatable deployment process reduces coordination errors.

Phase 1: Verify the Resource

Record:

• prefix
• IPv4 or IPv6
• resource holder
• RIR
• lease start
• lease end
• party controlling RPKI

Phase 2: Define Routing

Record:

• origin ASN
• upstream ASN
• deployment location
• BGP peer
• aggregate routes
• more-specific routes

Phase 3: Prepare Authorization

Prepare:

• ROA
• IRR route or route6 object
• LOA where required

Phase 4: Run Pre-Announcement Checks

Confirm:

• correct prefix
• correct ASN
• correct prefix length
• suitable maxLength
• ROA publication
• IRR alignment

Phase 5: Announce the Prefix

Start the planned BGP route.

Phase 6: Verify Externally

Check:

• route visibility
• origin ASN
• RPKI state
• reachability

Phase 7: Maintain Monitoring

The route should remain checked throughout the lease rather than only during deployment.

Build a Rollback Plan

RPKI and BGP changes should have rollback steps.

Document:

• previous ASN
• new ASN
• existing ROA
• replacement ROA
• BGP withdrawal process
• IRR rollback
• external route checks
• contact at the address provider
• conditions that trigger rollback

Do not remove a working authorization before the replacement routing state has been checked.

During a provider change, temporary overlap may be required depending on the architecture. Plan for overlap before the migration window starts.

Clean Up RPKI When an IP Lease Ends

Lease termination is part of route security.

A sound termination workflow should:

1. Stop production use of the leased addresses.
2. Withdraw the BGP announcement.
3. Confirm externally that the route has disappeared.
4. Remove customer-specific IRR records where appropriate.
5. Remove or replace ROA authorization that is no longer needed.
6. Update reverse DNS and related operational records.
7. Record the end of the customer’s routing authorization.

Leaving a previous origin ASN authorized after the commercial relationship ends creates unnecessary routing permission.

The same process applies when a customer stops using only part of a larger leased allocation.

RPKI for Leased IP Space Checklist

Before putting a leased IPv4 or IPv6 prefix into production, verify:

• exact prefix
• resource holder
• party controlling RPKI
• customer or provider origin ASN
• BGP announcement length
• ROA
• maxLength
• LOA requirements
• IRR object
• BGP configuration
• validation state
• route visibility
• external reachability
• monitoring
• migration sequence
• rollback plan
• lease-end cleanup process

A clear responsibility model helps both the lessor and lessee because many routing failures start with unclear ownership of a routing task.

Information Atal Networks Needs Before a BGP Announcement

Before announcing leased address space, we need the routing design to be clear.

Prefix Information

Provide:

• IPv4 or IPv6 prefix
• prefix size
• lease arrangement
• required announcement length

ASN Information

Provide:

• customer ASN, if used
• intended origin ASN
• provider ASN arrangement, if applicable

Routing Information

We also need:

• deployment city or data center
• BGP requirements
• upstream arrangement
• multihoming requirements
• planned more-specific routes
• BYOIP requirements

Authorization Information

Include:

• current ROA state
• required origin ASN
• intended prefix lengths
• IRR route or route6 object
• LOA where required

Change Information

For migrations, provide:

• planned cutover time
• current provider
• new routing arrangement
• rollback requirement
• technical contact

Getting these details before the first announcement reduces the chance of BGP and RPKI configuration disagreeing.

RPKI and IP Leasing With Atal Networks

Atal Networks provides IPv4, IPv6, and ASN leasing alongside dedicated hosting, private networking, BYOIP, and multihomed infrastructure options.

For a leased prefix, we recommend defining the routing relationship before production use:

prefix → origin ASN → ROA → IRR/LOA → BGP → external validation

This gives both parties a clear view of who manages each part of the deployment and makes later provider, ASN, or location changes easier to coordinate.

Discuss your prefix, ASN, routing arrangement, deployment locations, and RPKI requirements with Atal Networks.

Questions fréquemment posées

What is RPKI for IP leasing?

RPKI for IP leasing is the use of cryptographically verifiable route-origin authorization for leased IPv4 or IPv6 address space. The applicable ROA should authorize the ASN that will originate the leased prefix through BGP.

Who creates the ROA for leased IP addresses?

The organization with RPKI authority over the address resource normally creates the ROA unless that authority has been delegated through an applicable RPKI setup. Leasing a prefix does not automatically give the lessee RPKI authority.

Can a leased IP block use my own ASN?

Yes, if the routing arrangement supports it. The resource holder should authorize the customer’s ASN for the intended prefix before the customer originates that route.

Can the provider ASN originate a leased prefix?

Yes. If the provider originates the prefix, the ROA should authorize the provider ASN. This arrangement is common when the customer uses leased address space but does not operate its own public BGP ASN.

What does ROA maxLength mean?

maxLength sets the most-specific prefix length that the authorized ASN may originate under that ROA. It should match the real routing plan rather than permit more-specific routes that the network does not expect to advertise.

Why does my leased prefix show RPKI Invalid?

Common causes include the wrong origin ASN or a BGP announcement that is more specific than the ROA permits. Compare the live BGP prefix and origin ASN with the active authorization.

Is RPKI NotFound the same as Invalid?

No. NotFound, sometimes displayed as Unknown, generally means no applicable ROA covers the route. Invalid means a covering authorization exists but the announcement conflicts with it, such as an incorrect ASN or disallowed prefix length.

What is the difference between LOA, IRR, and ROA?

An LOA documents permission between organizations. An IRR object publishes routing-policy data. A ROA provides cryptographically verifiable route-origin authorization through RPKI. A production IP leasing arrangement may use all three.

Can the same prefix be authorized for multiple ASNs?

Yes. Separate ROAs can authorize several ASNs for the same prefixes where the routing design requires it. This can support provider migration, controlled multi-origin routing, cloud moves, or DDoS mitigation arrangements.

Does RPKI work for IPv6?

Yes. ROAs support both IPv4 and IPv6 prefixes. The same origin-authorization principle applies, although IPv4 and IPv6 use different prefix sizes and network structures.

Should the ROA be removed when an IP lease ends?

Authorization that is no longer required should be cleaned up as part of lease termination. Withdraw the BGP route first, confirm the routing change, then remove or update authorization according to the agreed operating process.

Does RPKI secure the complete BGP AS path?

No. Widely deployed RPKI origin validation focuses on route origin. It checks whether the originating ASN is authorized for the prefix rather than verifying every AS in the full BGP path.