Who Actually Owns an IP Address? (And Why It Matters for BYOIP)

IANA, the RIRs, holders and lessees: untangling who controls address space, what “ownership” means in practice, and what you have to prove before a cloud will announce your prefix.

Here is the answer nobody enjoys hearing: you probably do not own your IP addresses, at least not the way you own a laptop or hold a domain-name registration.

That sounds like pedantry right up to the moment it is not. The moment usually looks like this. You are filling in a BYOIP form at AWS, Google Cloud or Azure, and the provider asks you to prove you are entitled to the prefix you just typed in. Suddenly “we have had those addresses for years” is not an answer. The registry record is the answer.

So it is worth untangling the chain properly. A clean registry record will not guarantee a fast BYOIP request, but a stale one can stop the request before routing work even begins.

The short version

IP addresses are distributed as number resources: handed down a hierarchy and held under contract rather than sold as freehold title.

1. IANA, the Internet Assigned Numbers Authority, sits at the top of the tree and delegates large blocks to the regional registries.
2. The five RIRs (ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC) allocate and assign space within their service regions.
3. LIRs and end users, meaning ISPs, hosters, enterprises and cloud providers, receive allocations or assignments and become the holder of record for that space.
4. Everyone else who uses those addresses does so through the holder: as a customer, a tenant or a lessee.

In registry language you are the holder of a registered right of use. That right is real, transferable under policy and defensible in practice. It simply is not the same instrument as a deed.

The five RIRs at a glance

RIR	Service region	Where the record lives
ARIN	United States, Canada, parts of the Caribbean	whois.arin.net / ARIN Online
RIPE NCC	Europe, Middle East, Central Asia	whois.ripe.net / LIR Portal
APNIC	Asia-Pacific	whois.apnic.net / MyAPNIC
LACNIC	Latin America, Caribbean	whois.lacnic.net / MiLACNIC
AFRINIC	Africa	whois.afrinic.net / MyAFRINIC

Which registry your space sits in matters more than people expect. It sets your transfer policy, your RPKI options, your fee structure and, as we will see, whether a given cloud provider will accept your prefix at all.

“Ownership” versus the registered right of use

Every RIR issues space under an agreement: a registration services agreement, a membership contract, a set of terms and conditions. The wording differs between regions. The substance is consistent. You receive an exclusive right to use a block of numbers, conditional on meeting policy and paying fees, and the registry maintains the authoritative record of who holds it.

Whether that holding amounts to “property” in a legal sense is a genuinely open question, and the answer depends on jurisdiction rather than on the registry. Registries consistently describe what they issue as a right of use rather than as title. Some national courts and insolvency proceedings, on the other hand, have treated IPv4 registrations as transferable assets with real balance-sheet value, which is part of why a resale market exists at all. Both things can be true at once. For BYOIP purposes the distinction is largely academic, because the cloud provider is going to look at the registry record either way.

Two practical consequences follow, and both bite in BYOIP projects.

First, registrations are conditional. If a holder stops paying, dissolves, or is found to have obtained space on inaccurate information, the registry can begin de-registration or reclamation under its own published policy. How far that reaches into a contested case varies by region and by local law. The general point still holds: address space does not sit outside the agreement that created the registration.

Second, “selling IPs” means transferring the registration. The IPv4 market is genuine and large, but what changes hands is the registry record, through a policy-governed transfer. RIPE NCC has its transfer procedures, ARIN has specified-recipient and merger-and-acquisition transfers, APNIC has its own, and inter-RIR transfers exist between some regions but not all. There is no deed at the end of it. There is an approved registry ticket.

Then there is legacy space: blocks issued before the RIR system fully formed, often with a looser contractual relationship or none at all. Legacy holders frequently have the strongest historical claim and, ironically, the thinnest documentation. If you are bringing legacy space to a cloud, budget extra time for validation and expect to reconstruct a paper trail that predates most of the people reviewing it.

Who is who in a single prefix

A single /24 can have four different parties attached to it, and BYOIP touches all four. Keeping them separate is most of the job.

Role	What it means	Where you see it
Holder of record	The organization registered at the RIR as entitled to the block	WHOIS and RDAP, RIR portal
LIR or sponsor	The member organization that manages the resource on the holder’s behalf	RIR portal, mnt-by and sponsoring-LIR fields
User or lessee	Whoever is actually numbering machines out of the block	Nowhere authoritative, unless documented
Origin AS	The autonomous system announcing the prefix into BGP	The global routing table, IRR objects, RPKI ROAs

Here is the crucial insight for BYOIP: the holder and the origin AS are usually not the same organization. Bring a prefix to AWS and Amazon announces it from an Amazon ASN. Bring it to Google Cloud and Google announces it from a Google ASN. You stay the holder, they become the announcer, and all the paperwork exists to bridge that gap safely. If the term origin AS is new, the ASN primer covers it properly.

How to check who holds a prefix

Four sources, and they answer different questions. Mixing them up is the single most common cause of a failed BYOIP validation.

Source	What it proves	What it does not prove
WHOIS and RDAP	Who the registry says holds the block, plus contacts and status	That the holder authorized any particular announcement
RIR member portal	That you control the object, because you are logged in as the maintainer	Anything a third party can independently verify
IRR objects (route, route6, as-set)	That someone published a routing intention	Cryptographic authenticity; IRR data is famously stale
RPKI ROA	Cryptographically, that the holder authorized a specific ASN to originate the prefix	Who the holder is, in human terms

RDAP is the structured successor to WHOIS, and it is the interface that matters most for BYOIP. AWS, for example, asks you to publish a self-signed X.509 certificate into the RDAP record for your range as proof of control. If your RDAP contact data and remarks fields are a decade out of date, fix that before you start anything else.

Why BYOIP depends on all of this

BYOIP, stripped to essentials, is a permission problem. A cloud provider is about to announce your address space to the entire internet from its own network. Get that wrong and it becomes a hijacker. Major providers therefore evaluate three broad questions, although the order and evidence vary:

1. Are you the holder? Proven through registry data: RDAP or WHOIS records, sometimes a signed message, sometimes a Letter of Authorization.
2. Is the block eligible? Prefix-length floors and registry restrictions. A /24 is the practical minimum for IPv4 almost everywhere, because that is the smallest prefix the internet reliably accepts.
3. Did you authorize this specific ASN? Proven cryptographically with a Route Origin Authorization.

The specifics vary by provider, which is exactly why the BYOIP supporter directory exists. A few examples of how differently the same question gets asked:

Provider	Control proof	Authorization	Notable constraint
AWS	Self-signed X.509 certificate published in the RDAP record for the range	ROA authorizing Amazon ASNs 16509 and 14618; 8987 for GovCloud; or 16509 and 214101 for the European Sovereign Cloud	Most specific IPv4 range is /24; IPv6 is /48 publicly advertisable and /60 non-advertisable. Space must be registered with ARIN, RIPE or APNIC, to a business or institutional entity rather than an individual
Google Cloud	ROA plus a reverse-DNS (PTR) record pointing at a Google-supplied hostname	ROA authorizing 396982 for Premium Tier or 19527 for Standard Tier	Overlapping announcements are not supported, so the prefix cannot be advertised elsewhere at the same time
Microsoft Azure	Signed message plus registry validation	ROA authorizing Microsoft ASN 8075	Custom IP prefix ranges are validated before provisioning and commissioning

Same underlying question, who are you and did you say yes, in three different answer formats. The hyperscaler comparison walks through the rest of the differences.

Where leasing fits

This is the part that trips up procurement teams. If you lease IPv4 space rather than holding it directly, can you still do BYOIP?

Often yes, but the authorization has to come from the party the registry recognizes. The lessor is the holder of record, so the lessor creates the ROA and signs any Letter of Authorization naming the cloud’s ASN. You get to use the addresses and keep their reputation history; the paperwork routes through whoever the registry says is in charge.

Which means the practical question when you lease is not “how cheap is the /24” but “will this provider create and maintain a ROA for the ASN I need, on my timeline, and withdraw it cleanly when I leave?” Some providers treat that as a routine self-service action. Others route it through a support queue. The difference can add days to a project, which is a good reason to compare the IP providers on that specific capability before signing anything.

Four misconceptions worth retiring

“We bought these addresses in 2004, so they are ours.” You very likely hold a valid registration, possibly legacy, and that is a strong position. Now check that the record still names the right legal entity. Mergers, rebrands and acquisitions leave a trail of orphaned objects, and a mismatch between your company name and the registry record will stall a BYOIP request instantly.

“We announce it, so we control it.” Announcing a prefix is not a claim of entitlement. It is just a BGP message. That asymmetry is precisely why RPKI exists.

“WHOIS says us, so we are done.” WHOIS proves registration, not authorization. Clouds want both, and increasingly they want the authorization half in cryptographic form.

“An IP address is like a domain name.” Tempting, but no. Domain names are registered through registrars in a system built around renewals and open transfers between more or less anyone. IP space is allocated under needs-based and policy-based frameworks, with regional rules, transfer approval and eligibility criteria.

A pre-flight checklist

Before you open a BYOIP request anywhere, confirm that:

• The RDAP or WHOIS record for your prefix names your current legal entity, with working contacts.
• You know which RIR holds the block, and your account there is accessible.
• The block is registered to an organization rather than to a named individual, which some providers require explicitly.
• Your prefix meets the selected provider's size and address-family requirements. A /24 is the usual IPv4 floor; IPv6 requirements vary by provider and advertisement model.
• You can create or request a ROA, whether directly, through your LIR or through your lessor.
• The prefix is not being announced anywhere else, or you have a clean cutover plan.
• If the space is leased, your contract explicitly covers ROA creation, maintenance and withdrawal.

Seven boxes. Most BYOIP delays trace back to one of them, and the ones that do not usually trace back to the gaps between systems that BYOIP automation is meant to close.

FAQ

Where to go next

Ownership is gate one of three. Gate two is the origin AS that will actually announce your prefix. Gate three is the ROA that authorizes it.

• What Is BYOIP? A Practical Guide to Bringing Your Own IP Addresses
• What Is an ASN? The Number Behind Every BYOIP Announcement
• What Is RPKI? ROAs, Origin Validation and Your BYOIP Prefix
• BYOIP on AWS, Google Cloud and Azure: What Actually Differs?
• Browse BYOIP supporters and their per-provider validation requirements
• Compare IP providers on ROA handling before you lease or buy

References

• IANA - Number Resources
• NRO - The Regional Internet Registries
• ARIN - Whois and RDAP services
• ARIN - Registration Services Agreement and related agreements
• RIPE NCC - Resource transfers and mergers
• APNIC - Transferring resources
• LACNIC - Registry services
• AFRINIC - Registry services
• RFC 9082 - Registration Data Access Protocol (RDAP) Query Format
• RFC 6811 - BGP Prefix Origin Validation
• ARIN - Resource Public Key Infrastructure (RPKI)
• AWS - Bring your own IP addresses (BYOIP) to Amazon EC2
• Google Cloud - Bring your own IP addresses
• Google Cloud - Create a public advertised prefix
• Microsoft Azure - Custom IP address prefix (BYOIP)