Do You Need an ASN to Announce Leased IPv4? Four Routing Paths, Compared
Some leasing providers will not sign a contract until you give them an AS number. Others will not let you use yours at all. Both are right, because they are describing different routing paths - and only one of the four available actually requires an ASN of your own.
Artem Kohanevich
Co-Founder & CEO at IPbnb
Last updated
Table of Contents
item
No. Not always.
You need an ASN somewhere in the routing chain, because that is how BGP identifies who is allowed to originate your prefix. But it does not have to be yours. Four announcement paths exist, and three of them work without you ever applying to a Regional Internet Registry.
Which one fits depends on how many upstreams you have, where the workload runs, and how much control you need over inbound traffic. Here is the whole decision on one screen.
Path | Your own ASN? | Who originates the prefix | Realistic setup time | Routing control | Best for |
|---|---|---|---|---|---|
1. Your ASN, your BGP | Yes | You | Weeks - RIR application, then peering | Full: multihoming, traffic engineering, failover | ISPs, telecoms, multihomed operators |
2. Upstream or host announces for you | No | Your provider | Days | None - you inherit their routing policy | Single-homed hosting and colocation customers |
3. Cloud BYOIP | Optional | The cloud's ASN by default; AWS also supports announcing under your own ASN via BYOASN | Days, plus validation | Limited by each provider's programme | Cloud-native workloads on AWS, Azure, GCP |
4. A third party's ASN | No | Your partner's AS | Days | Contractual, not technical | Proxy operations, data collection, short projects |
The rest of this guide walks through each path, the paperwork that changes with it, and the one technical rule that decides whether your subnet routes at all. If you are earlier in the process and want the end-to-end picture first, start with the full leasing workflow.
First, the contradiction nobody in this market names out loud
Read two leasing providers' documentation side by side and you will get opposite answers to the same question.
Some lessors treat an ASN as a hard prerequisite. RapidSeedbox will not complete a lease without one and tells customers who lack an ASN to obtain it from their VPS or hosting provider. Voldeta states plainly that to rent an IPv4 subnet and announce it you must have an ASN - your own or a third party's - and adds that the ASN must carry a clean reputation and must not appear on Spamhaus.
Other providers refuse to let you use your own. Leaseweb announces customer prefixes exclusively from Leaseweb AS numbers; advertising a prefix under the customer's own ASN is not offered at all. Instead they ask for delegated mnt-routes on RIPE blocks, or a Letter of Authorization from the registered holder.
Neither camp is wrong. They are describing two different paths, and each has quietly assumed its own path is the only one. That assumption is where most of the confusion around leased IPv4 comes from.
What an ASN actually does here
Skip this section if you already run BGP.
An Autonomous System Number identifies a set of IP prefixes operating under a single routing policy. When two networks exchange routes, they identify themselves by ASN and advertise which prefixes they can reach. RFC 1930 describes an ASN as the unit of routing policy in exterior routing, which remains the most precise short definition available.
Two formats are in use. The original 16-bit space provided 65,536 numbers and is effectively exhausted at RIR level; new assignments come from the 32-bit space defined in RFC 6793, which obsoleted RFC 4893. Returned or reclaimed 16-bit numbers occasionally recirculate, but you should plan on receiving a 32-bit ASN.
For a leased subnet, only one property of the ASN matters: it is the identity attached to the route. Whoever originates your prefix in BGP puts their AS number on it. That number then has to match what the paperwork says. Everything below follows from that single constraint.
Path 1: Your own ASN, your own BGP session
You apply to your RIR for an AS number, establish BGP sessions with your upstreams, and originate the leased subnet yourself.
What changes in the paperwork. The IP owner - or the leasing platform acting for them - issues an LOA naming your ASN, creates or updates the IRR route object binding the block to your ASN, and creates the ROA authorising your ASN to originate the prefix. All three point at you. The mechanics of that authorisation, and why owners retain control throughout, are covered in our guide to who issues the LOA and why owners keep control.
What you gain. Genuine multihoming. You can move the subnet between upstreams without renumbering, engineer inbound traffic with prefix-length and AS-path controls, and survive a transit provider failing without losing your addresses. For an ISP or a telecom, this is not a preference - it is the reason the business has a routing table.
What it costs. Under the RIPE NCC Charging Scheme 2026 (ripe-848), an LIR account costs EUR 1,800 per year with a EUR 1,000 sign-up fee, plus EUR 50 per ASN assignment. Members voted in May 2026 to adopt Option A for 2027: EUR 1,894 per LIR account, with the first ASN included in the annual fee and EUR 50 charged per additional ASN. If you do not want to become an LIR, you can request an ASN through a sponsoring LIR, which charges its own fee, or submit the request to the RIPE NCC directly - ripe-679 permits both routes. We have a full breakdown of RIPE NCC membership costs if you are weighing LIR membership against a sponsored arrangement.
When it is the wrong move. If you have one upstream and one /24, an ASN buys you administrative overhead and nothing else. You will still depend on a single provider for reachability, you will now carry registry obligations and recurring fees, and your routing policy will be identical to your upstream's. This is worth saying clearly, because the market rarely does: most IP renters do not need their own ASN, and the companies selling ASN registration services are not the best people to ask.
Path 2: Your upstream or host announces the subnet for you
The most common arrangement, and the one most leasing guides ignore entirely.
Your hosting provider, colocation facility, or transit supplier originates the prefix from their AS. You do not run BGP. You do not touch a router. The subnet appears on your servers and traffic arrives.
What changes in the paperwork. The LOA is issued to your provider, not to you. The route object and the ROA name their ASN as origin, not yours. This is the detail that trips people up: renters sometimes ask their IP owner to create a ROA for an ASN they do not actually announce from, then wonder why nothing routes.
Practical constraints to check before signing. Most providers set a minimum announceable size of /24 for IPv4 - anything longer is filtered globally, regardless of who originates it. Many aggregate announcements and will not de-aggregate on request. Some cap the number of external prefixes they will carry per customer, or charge a setup fee per block.
What you give up. Portability and control. Because the announcement lives with your provider, changing providers means a new LOA, a new route object, a new ROA, and a re-announcement. The addresses stay yours to lease, but the routing does not follow you automatically.
Path 3: Cloud BYOIP
Bring Your Own IP programmes let you import a leased block into a public cloud and use it on cloud resources. What follows covers the ASN question specifically; for the full onboarding sequence on each platform, see our provider-by-provider BYOIP guide.
AWS. BYOIP in commercial regions authorises announcements from Amazon ASNs 16509 and 14618; the AWS GovCloud (US) region uses ASN 8987. For IPv4 the ROA must be created with a maximum length of /24. Authorisation has two halves: the ROA proves the addresses may be advertised, and a self-signed X.509 certificate published in the RDAP remarks for the block proves the AWS account bringing them is yours. AWS documents validating the result through the RIPEstat RPKI validation data call, which works regardless of which RIR administers the space.
AWS also supports bringing your own ASN. Through IPAM you can associate an ASN you hold with a BYOIP CIDR and have AWS advertise the prefix under your AS rather than Amazon's. This is the one place where cloud deployment and your own ASN are not mutually exclusive - and it is worth knowing before you conclude that BYOIP means surrendering your routing identity.
Azure. Supported through Custom IP Prefix. The ROA must authorise origin AS 8075 for the public cloud, or 8070 for US Gov, and must be signed with your RIR's RPKI. A unified or parent IPv4 prefix must be between /21 and /24. Once commissioned, Microsoft advertises the range globally from AS 8075 - announcing the same range from anywhere else at the same time risks routing instability, so migrations need a maintenance window. Two further constraints decide whether Azure is viable at all: SMTP is not permitted from Azure BYOIP space, so this path is unsuitable for mail workloads; and the range must be decommissioned before you modify or delete the ROA, or Microsoft will continue advertising a prefix it is no longer authorised to announce.
GCP. Supported, with its own onboarding requirements.
What to watch across all three. Each cloud imposes its own minimum prefix size, regional constraints, and validation timeline. Because your IP owner holds registry control, the ROA and RDAP steps cannot be completed by you alone - they have to be coordinated with the owner or the leasing platform. And if the reason you are leasing is to preserve a stable set of addresses behind partner allowlists, the constraints in this section matter more than usual - see keeping leased addresses inside partner allowlists.
Path 4: Announcing from a third party's ASN
Common in proxy, data collection, and short-lived project work. A partner who already operates an AS announces the subnet on your behalf under a commercial agreement.
What changes in the paperwork. Same shape as Path 2 - LOA, route object, and ROA all name the partner's ASN. The difference is that your relationship with the announcing party is purely contractual, and often shorter than the lease itself.
The reputation question. Voldeta's requirement applies to every arrangement of this kind: the announcing ASN needs a clean record. A subnet with a spotless history announced from an AS with a poor one will inherit problems - mail deliverability first, then filtering. Check the ASN, not only the block.
The exit risk. If the partnership ends before the lease does, you need a new announcing party, a new LOA, a new route object, and a new ROA - and a gap in any of those means the subnet stops routing. Write the handover into the agreement before you need it.
The rule that decides whether any of this works
The ASN in the ROA must match the AS that actually originates the route.
That is the whole thing. Every failure mode below is a variation of it.
A Route Origin Authorization is a signed statement from the resource holder saying which ASN may originate a given prefix, and up to what prefix length. In the RIPE region, ROAs are created by the registered holder in the RIPE NCC RPKI Dashboard - the IP owner, not the IP renter. Alongside it sits the IRR route object, which ties the inetnum to a specific ASN and thereby authorises that ASN to announce the block.
RFC 6811 defines three validation states:
NotFound - no ROA covers the prefix. Most networks still accept these routes, but the share that does is shrinking as RPKI adoption grows. Note that RIPEstat reports this state as "unknown" in its API output, which is a common source of confusion.
Valid - ROA present, origin ASN and prefix length both match. This is the target.
Invalid - ROA present but the origin ASN is wrong, or the announced prefix is longer than the ROA's maximum length. Every network performing Route Origin Validation drops the route. The failure looks like a mysterious partial outage rather than a configuration error.
If RPKI is unfamiliar territory, our beginner's guide to how RPKI and ROAs actually work covers ROA creation, max-length errors, and what a wrong ROA costs you.
Two consequences follow directly:
Decide your path before the ROA is created. If your host announces for you, the ROA names their ASN. If you use Azure Custom IP Prefix, it names 8075. Creating a ROA for your own ASN and then asking a provider to announce the block is the single most common self-inflicted routing failure in leased space.
If your ASN changes mid-lease, the ROA and route object must change with it. This is not automatic. It is a request to your IP owner or leasing platform, and it needs to happen before the cutover, not after.
Can a /24 be announced from your ASN while the covering aggregate stays announced from the owner's? Yes. Operators have done this for years. The more-specific wins on longest-prefix match, so traffic lands with you. What makes it work is correct route objects and a matching ROA for the more-specific; what makes it fail is announcing without them and having the route treated as a hijack. If you are relying on the more-specific alone, note that you cannot reliably multihome away from the owner's upstream unless the paperwork covers every path.
Do I qualify for my own ASN?
Multihoming is the policy test, and it is stricter than most articles suggest. ripe-679 section 2.0 states directly that a network must be multihomed in order to qualify for an AS Number, and that a new ASN should only be used where a new external routing policy is required. When you apply, you supply that routing policy in RPSL, and the RIPE NCC may contact your upstreams to verify the arrangement.
This is worth stating precisely, because the picture changed very recently. Policy proposal 2025-01, "ASN assignment criteria revisited," would have removed all justification requirements for an organisation's first ASN. Its authors argued that 32-bit ASNs are no longer scarce - RIRs have assigned roughly 88,400 of them, around 0.002% of the available space - and that the multihoming rule is unenforceable in practice, since about half of RIPE NCC-assigned ASNs do not meet it. The proposal reached version 2.0, was discussed through RIPE 92 in Edinburgh in May 2026, and was withdrawn on 6 July 2026. The existing criteria in ripe-679 remain in force. If you have read elsewhere that RIPE is about to make first ASNs available on request, that is no longer accurate.
A unique routing policy sounds harder than it is. It does not mean you must use different transit providers from everyone else. Two organisations using the same two upstreams still have distinct routing policies, because each controls its own address space and its own announcements.
Pre-announcement checklist
Run this before any traffic is directed at the subnet, regardless of path. If you are moving live services rather than standing up something new, the full zero-downtime migration sequence covers DNS TTL preparation and parallel operation on top of these steps.
[ ] LOA issued, naming the announcing ASN, valid for the lease term
[ ] IRR route object created for the prefix with the correct origin ASN
[ ] ROA created, correct ASN, maximum prefix length matching what will be announced
[ ] Prefix validates as Valid - check via the RIPEstat RPKI validation data call, a Routinator instance, or another maintained relying-party implementation such as rpki-client or FORT. Do not use the RIPE NCC RPKI Validator: it has been unmaintained since 1 July 2021, and the public service at rpki-validator.ripe.net was migrated to Routinator in September 2021.
[ ] Prefix visible from multiple vantage points - RIPE RIS, BGPView, or the Hurricane Electric toolkit
[ ] Origin ASN observed in the wild matches the ASN in the ROA
[ ] Reverse DNS delegated
[ ] Block reputation checked against major blocklists, and the announcing ASN's reputation checked too
Once the subnet is live, the routing setup becomes an inventory problem: lease expiry dates, reputation checks, and subnet assignments all need tracking across the lease term.
FAQ
Can I lease IPv4 without an ASN?
Yes. Three of the four paths above require no ASN of your own. What you cannot do is have the subnet routed without some ASN originating it.
Can two different ASNs announce parts of the same block?
Yes. A more-specific subnet can be announced from one ASN while the covering aggregate is announced from another. Both need correct route objects, and the more-specific needs a ROA whose maximum prefix length permits it.
Does the announcing ASN's reputation matter?
Yes, and it is under-checked. Blocklist operators and mail receivers look at origin AS as well as address history. Some lessors will refuse to authorise an announcement from an ASN with a poor record.
What if my ASN changes during the lease?
The ROA and IRR route object must be updated by the IP owner before you announce from the new AS. Plan a window; do not cut over and hope.
Can I announce a leased /24 out of someone else's larger allocation?
Yes, with an LOA and correct registry objects. This is standard practice, not an exception.
Is RIPE about to drop the multihoming requirement?
No. The proposal that would have done so, 2025-01, was withdrawn on 6 July 2026. ripe-679 stands unchanged.
Can I use leased IPv4 in Azure for sending email?
No. Azure does not permit SMTP from BYOIP address space. If mail is the use case, choose a different deployment path.
