Do You Need Your Own ASN to Lease IPv4 Addresses?

No, you can lease IPv4 without ASN ownership, as long as a hosting provider or another authorized network originates the route for you. You generally need your own public ASN when your network will appear as the origin of the prefix in public BGP routing. Before ordering, confirm the announcing ASN, receiving-provider approval, routing authorization and how traffic will reach your infrastructure.

ARIN’s RPKI FAQ explicitly explains that an organization without a public ASN can use its upstream provider’s ASN as the origin in a Route Origin Authorization.

For buyers, the useful question is: “Which network will announce these addresses, and who will deliver them to our servers?” Answer that first, and the ASN requirement becomes much clearer.

Key Facts

• You can lease IPv4 without ASN of your own: you can lease IPv4 when a hosting provider or another authorized network announces the addresses for you.
• The origin ASN determines routing authorization: ROAs must authorize the network actually originating the prefix.
• BGP support does not always include announcement: confirm whether your provider originates the route or expects you to do so.
• An announcement is only part of deployment: traffic must also reach your servers through a supported delivery path.
• Provider approval comes before ordering: verify the prefix, hosting product, location and any cloud BYOIP requirements.
• Plan for future moves: retaining the same IPs when changing networks depends on your lease, authorization updates and the new provider’s acceptance.

What is an ASN and how does it relate to IPv4 leasing?

An Autonomous System Number identifies a network operating under a common routing policy. Border Gateway Protocol, or BGP, allows networks to exchange information about how to reach IP prefixes.

An IPv4 lease gives your business contractual permission to use specified address space. An ASN identifies a routing network. These are separate resources: leasing addresses does not automatically provide an ASN, internet connectivity or a BGP service.

There are also three distinct roles:

Resource holder: the organization holding the registered address resources and the authority needed to authorize their use.

Origin network: the network whose ASN originates the prefix in public BGP.

Hosting or receiving network: the infrastructure where your servers and applications run.

One organization may perform several roles, but they can also belong to different companies. ARIN’s ASN guide explains the relationship between autonomous systems and routing policy.

Three ways to deploy leased IPv4 addresses

Deployment option	Public origin ASN	Do you need your own ASN?	Main requirement
Your network originates the prefix	Your ASN	Yes, for this arrangement	BGP connectivity, authorized announcements and operational support
Your hosting provider originates the prefix	Hosting provider’s ASN	No	Provider approval for externally leased addresses and delivery to your servers
Another network originates and delivers the prefix	Third-party network’s ASN	No	An agreed delivery path, compatible receiving infrastructure and clear responsibilities

The decisive detail is the origin ASN, rather than simply whether a provider says it “supports BGP.”

1. Announce leased IPv4 through your own ASN

This option suits businesses that operate a routing network and need control over upstream connections, routing policy or multiple infrastructure locations.

Your network originates the leased prefix under your public ASN. Your transit providers then carry the announcement according to their policies.

Before choosing this arrangement, confirm that:

• Your upstream providers accept the prefix and its authorization.

• Your routers and team, or managed network operator, can support the BGP configuration.

• The relevant Route Origin Authorization and Internet Routing Registry records match the planned announcement.

• Monitoring, incident response and routing changes have an assigned owner.

Having an ASN alone does not make the addresses reachable. You still need connectivity, accepted routing announcements and working delivery to the machines using the IPs.

If your team only needs additional addresses on hosted servers, compare this approach with provider-originated routing before taking on network operations.

2. Have your hosting provider announce the addresses

If your hosting provider accepts externally leased IPv4 space, it may originate the prefix under its own ASN and route the addresses to your dedicated servers, virtual machines or other supported infrastructure.

You can use the leased addresses without operating your own public ASN or internet-facing BGP sessions.

However, ask precisely what the provider supports:

• “We announce your leased prefix under our ASN” means the provider is the public origin.

• “We give you a BGP session” may mean your network is expected to originate the prefix under your own ASN.

Those offers have different requirements. Get written confirmation for the exact hosting product and location you intend to use. Support in one data center or service does not establish support across the provider’s entire platform.

3. Use another announcing network

A third-party network can originate the prefix while your applications run elsewhere. The addresses then need an agreed delivery method between that network and your infrastructure.

Depending on the service, delivery might use a tunnel, a private connection or another supported routing arrangement. PubConcierge’s IP leasing FAQ describes options including GRE tunneling, dedicated servers, VPS infrastructure and routing to a customer’s server.

An announcement and a delivery path are separate requirements. Internet traffic can reach the announcing network while still failing to reach your application.

For a tunneled deployment, confirm endpoint compatibility, bandwidth, latency, MTU, redundancy and support ownership. Also confirm that the return path and source-address filtering allow traffic using the leased addresses. Treat these as acceptance criteria for the proposed design.

Do cloud BYOIP services require your own ASN?

Not necessarily. A cloud platform can announce accepted addresses using its own ASNs. However, an IPv4 lease is not automatic approval for Bring Your Own IP onboarding.

For example, Amazon EC2’s BYOIP prerequisites include resource verification and ROAs authorizing specified Amazon ASNs. The most specific IPv4 prefix supported by that service is /24.

The practical lesson is to validate the actual prefix and authorization arrangement against the receiving platform’s current requirements. Confirm who can complete registry verification, publish required records and provide any additional proof of control.

A valid lease and a standard Letter of Authorization may not, by themselves, satisfy a platform’s onboarding process.

How LOA RPKI and IRR requirements depend on the origin ASN

Once the announcing network is selected, align the authorization with it.

Item	What it establishes	What customers should confirm
Lease agreement	Contractual permission to use the specified addresses	Prefix, permitted use, term and authority to supply the resources
Letter of Authorization, or LOA	Written authorization requested by a receiving network	Accepted format, authorized party, prefix and intended announcement
RPKI Route Origin Authorization, or ROA	Cryptographic authorization for an ASN to originate a prefix within permitted prefix lengths	Correct origin ASN and prefix-length coverage
IRR route object	Registered prefix and origin information used by some networks for routing filters	Accepted registry, correct origin and who maintains the object

The ROA must authorize the actual origin ASN. Do not assume it should name the leasing customer or every transit provider carrying the route.

For example, if your host originates a leased prefix under its ASN, authorizing only an unrelated customer ASN will not validate that announcement. Likewise, a permitted ASN can still produce an RPKI Invalid route if the announced prefix length exceeds the authorization.

For implementation details, read PubConcierge’s guide to RPKI in IP leasing and secure routing.

What should you confirm before ordering leased IPv4?

Use this checklist with both the leasing company and the receiving network.

Confirm before ordering	Ask for this specific answer
Receiving-provider acceptance	“Will you accept this externally leased prefix on this product and in this location?”
Origin ASN	“Which ASN will originate the route in public BGP?”
Prefix size	“What block sizes can the lessor supply and the receiving network announce?”
Authorization	“Who supplies the LOA and maintains the ROA and required IRR records?”
Traffic delivery	“How do incoming traffic and replies travel between the announcing network and our servers?”
Operational limits	“Which bandwidth, port, MTU, source-filtering or acceptable-use restrictions apply?”
Additional charges	“Are announcement, tunnel, transit, setup and support fees included?”
Testing and billing	“What can we test, what counts as acceptance, and when does billing begin?”
Future changes	“Can we change origin ASN or hosting provider, and what fees or lead times apply?”
Incident ownership	“Who handles route withdrawal, invalid authorization, delivery failure and emergency changes?”

Keep the answers together in the order specification. “IPv4 supported” is too broad to establish that a particular deployment will work.

Can you keep the same IPv4 addresses when changing ASN?

Potentially, yes. Keeping the addresses and keeping the announcing network are separate decisions. Whether a move is possible depends on the lease, resource authorization and receiving-provider acceptance.

Consider this illustrative scenario: A company leases a prefix that Hosting Provider A originates. Later, the company wants Hosting Provider B to originate the same prefix.

The prefix does not inherently need to change. However, the migration requires acceptance by Provider B, authorization for its origin ASN, appropriate routing-record updates and a coordinated withdrawal and announcement plan. Delivery, reverse DNS and application behavior also need checking.

AWS’s BYOIP documentation specifically warns that authorization changes during migration can affect existing announcements. Plan the order of changes before modifying a live ROA.

Before signing, ask who controls these updates and how quickly they can be completed. For a business with customer allowlists or long-lived integrations, that answer can matter as much as the monthly IP price.

Test the final deployment rather than only the address list

Routing approval does not establish application suitability. A prefix can be visible in BGP while a tunnel, firewall or return-path issue prevents a service from working.

Before production, verify:

• The observed origin ASN matches the agreed deployment.
• The route has the expected RPKI status and visibility.
• Representative external networks can reach the required services.
• Outbound connections use the expected leased addresses.
• Geolocation, reputation and reverse DNS meet the agreed workload criteria.
• The application works through the proposed production delivery method.

Use PubConcierge’s guides on checking IP reputation before leasing and testing leased IPs before commitment to define the wider acceptance process.

Plan your IPv4 deployment with PubConcierge

PubConcierge combines IPv4 sourcing with technical setup, routing coordination and infrastructure services. The appropriate arrangement depends on your workload, receiving network and available resources.

Send the team your required IP quantity, hosting provider and location, intended use, and preferred announcing arrangement. If you already have an ASN, include it. If you do not, ask about supported provider-originated delivery options.

Request free IPv4 testing and confirm the available test scope, delivery method and technical responsibilities before committing.

Test for Free

Frequently asked questions about lease IPv4 without ASN ownership

Yes, if a hosting provider or another authorized network originates the prefix and delivers the addresses to your infrastructure. Confirm this arrangement before ordering.

Does an LOA mean I need my own ASN?

No. An LOA can support an arrangement in which another network announces the addresses. Its content must meet the receiving network’s requirements.

Does my ASN need to match the registered IPv4 holder?

No. With appropriate authorization, one organization can hold the address resources while another network originates the prefix. Confirm that the lease and routing records support that arrangement.

Do I need to run BGP myself?

Not when a provider handles origination and delivery as an included service. If your network originates the prefix, BGP operations must be handled by your team or an appointed operator.

Will a different ASN fix IP reputation or geolocation?

Do not assume it will. ASN changes, reputation, geographic recognition and application acceptance require separate checks. Test the final deployment against the databases and services relevant to your workload.

Stay up to date on growth infrastructure, email best practices, and startup scaling strategies by following PubConcierge on LinkedIn.