What Is a Letter of Authorization (LOA) in IP Leasing? LOA vs ROA and What to Verify

A Letter of Authorization (LOA) is a formal document in which the registered holder of an IP address block authorizes another party to announce that address space from a specified Autonomous System Number. It is the written permission that connects a contractual right to use address space with the technical act of routing it — and without it, upstream providers will generally refuse to accept your announcements.

That refusal is what makes the LOA operationally decisive rather than merely administrative. Transit providers, data centres, and carriers require proof that whoever is announcing a prefix is actually authorized to do so, because accepting an unauthorized announcement means participating in a hijack. Cloudflare’s BYOIP documentation states the requirement plainly: its transit providers require an LOA before they will accept the routes Cloudflare advertises on a customer’s behalf, and the document must specify the prefixes being authorized and the ASN they will be announced under. The same expectation applies across the industry. A business can hold a signed lease, have its routers configured, and still be unable to bring services online because the LOA has not arrived.

There is also a conceptual point the document makes concrete, and it matters for anyone leasing address space: an LOA authorizes announcement — it does not transfer ownership or change registration. The space remains registered to the holder; what the LOA grants is permission to route it. This article explains what an LOA contains, why providers require it, how it differs from a ROA and an IRR route object, who can legitimately issue one, and exactly what to verify before you pay for address space you intend to announce.

What Is a Letter of Authorization?

An LOA is a signed statement from the registered holder of IP address space granting a named party permission to announce specified prefixes from a specified ASN. Sometimes called a Letter of Agency, it is a human, contractual document — written, signed, and read by people at upstream providers — rather than a technical record consumed by routers.

Its function is to answer a question the routing system cannot answer on its own. Public registry data shows which organization holds a block, but it does not show who that holder has permitted to announce it. When a network other than the registered holder wants to originate a prefix — a lessee announcing leased space, a provider announcing a customer’s block, a platform announcing a customer’s BYOIP prefixes — the upstream needs evidence that the arrangement is authorized. The LOA is that evidence.

Two properties define it:

• It is issued by the holder, not the announcer. The party with the authority to grant permission is the one that holds the space. A lessee cannot write their own LOA.
• It is specific. It names particular prefixes and a particular ASN. A general statement of good standing is not an LOA; the document has to match exactly what will be announced.

Why Do Upstream Providers Require an LOA?

Providers require an LOA because accepting an announcement from a party with no authorization is how prefix hijacking happens — and no responsible network wants to be the one that propagated it.

As we explain in our guide to how BGP works, the routing system accepts announcements largely on trust, and networks filter what they accept precisely because a false announcement can redirect someone else’s traffic. That risk is not theoretical: unauthorized announcements are the mechanism behind the incidents described in our guide to BGP hijacking. An upstream provider that accepts an announcement without verifying authorization becomes an unwitting participant in whatever follows.

The LOA resolves a specific gap. Registry records identify the holder, but in a lease the records still show the holder while a different party does the announcing — so the upstream cannot verify the lessee by database lookup alone. The LOA supplies the missing link: written confirmation from the party the records do identify that the party doing the announcing has permission.

The practical consequence is that the LOA sits on the critical path to deployment. Routers configured, lease signed, block allocated — none of it produces reachability until the upstream accepts the announcement, and the upstream will typically not accept it without the document.

What’s in an LOA?

An LOA identifies the authorizing holder, the authorized party and ASN, the exact prefixes, and the signature of someone empowered to grant the authorization. The standard components, consistent across providers:

• The authorizing party. The registered holder of the address space, identified by company name and details matching the registry records.
• The authorized party and ASN. Who is permitted to announce the space, and critically, from which Autonomous System Number. Cloudflare’s documentation specifies that the LOA must state both the prefixes authorized and the ASN they will be announced under — the ASN is not optional detail.
• The exact prefixes. The specific address blocks covered, written precisely (for example, a particular /24). Announcements outside what the LOA names are not authorized by it.
• Validity period. The duration of the authorization, which for leased space should align with the lease term.
• Authorized signatory. The name, title, and signature of a person empowered to sign on the holder’s behalf, with contact details so the upstream can verify if needed.
• Company letterhead and format. LOAs are expected as formal documents on the holder’s letterhead. Cloudflare notes that transit providers may reject an LOA submitted as an image file and require PDF, and that digital signatures are acceptable provided the signer is clearly identified.

These requirements are not bureaucratic ornament. Letterhead, matching company details, and an identifiable authorized signatory are how the receiving provider satisfies itself that the document is genuine and that the signer could actually grant the permission claimed.

When Is an LOA Required?

An LOA is required whenever a party other than the registered holder will announce address space — which covers most leasing, BYOIP, and provider-announcement scenarios. The common cases:

• Announcing leased IPv4 from your own ASN. The classic case: you lease a block and announce it yourself, so your upstream needs the holder’s authorization. The broader leasing process this fits into is covered in our IPv4 leasing guide and our walkthrough of how IP address leasing works.
• Having a provider announce space on your behalf. When your hosting provider, data centre, or a platform announces your prefixes from their ASN, they need your authorization to do so — and their upstreams need to see it.
• BYOIP onboarding. Bringing your own IP space to a cloud or edge platform requires authorizing that platform to advertise your prefixes, as the Cloudflare requirement illustrates.
• Emergency routing changes. Arrangements such as DDoS scrubbing, where a provider must announce your prefix during an attack, depend on authorization being in place beforehand — a point we cover in our guide to DDoS mitigation.

The unifying test is simple: if the announcing ASN is not the registered holder’s own, an LOA is almost certainly needed.

LOA vs ROA vs IRR Route Object

An LOA, a ROA, and an IRR route object all say who may announce a prefix — but they say it to different audiences, in different forms, at different layers. They are complements, not alternatives, and a properly deployed prefix usually needs all three aligned.

The clearest way to hold the distinction: the LOA is how a human at your upstream decides to configure the session; the ROA is how routers across the Internet decide whether to accept the announcement; the route object is how automated filters decide whether to admit it. They can each fail independently, and each failure produces a different symptom — which is why deployments stall in confusingly different ways depending on which record is missing.

The three also increasingly interact. Cloudflare’s auto-generated LOA process, for instance, relies on RPKI-signed ROAs and ownership validation checks — cryptographic records supporting the human document rather than replacing it. For the mechanics of ROAs, including how they authorize a specific origin ASN and what happens when they are misconfigured, see our guide to RPKI and ROA.

Who Can Legitimately Issue an LOA?

Only the registered holder of the address space — or a person authorized to act on the holder’s behalf — can legitimately issue an LOA. This is the point where the document’s meaning must be stated precisely, because it is frequently blurred.

Three distinctions worth keeping separate:

• An LOA authorizes announcement; it does not transfer ownership. Signing an LOA grants permission to route address space. It does not make the authorized party the holder of that space, does not change registry records, and does not convey any registry-level rights. When the authorization ends, the permission ends with it.
• Registration stays with the holder throughout a lease. In a leasing arrangement, the registry continues to show the holder as the registered party. That is not a gap in the arrangement — it is the structure of it. The lessee’s right to announce derives from the authorization granted, not from any change in registration.
• Announcing is not the same as holding. A network announcing a prefix is originating it, which reflects authorization. It is not evidence of ownership, a distinction that matters both conceptually and practically, since unauthorized announcement is precisely what hijacking is.

For the receiving upstream, these distinctions translate into a verification question: does the signer actually have the authority they claim? That is why LOAs are expected on the holder’s letterhead, with company details matching registry records, signed by an identifiable person with a title. A document that cannot be traced back to the registered holder is not an authorization — it is an assertion.

LOA and Leased IPv4: What to Verify Before You Pay

Because the LOA sits on the critical path to routing, its handling should be settled before money changes hands — not discovered afterward. The failure mode is well known in the industry: a business signs a lease, configures routing, notifies its upstream, and is then asked for an LOA that the lease never mentioned and the lessor is slow to produce. The addresses are paid for and unusable until the document arrives.

What to establish up front:

1. Get the LOA before paying, or get a written delivery commitment. Either the document in hand, or a term in the agreement specifying delivery within a defined, short window. A lessor that will not commit to either is telling you something about how the rest of the relationship will run.
2. Verify it names the correct prefixes. Exactly the blocks you are leasing, written precisely. An LOA covering a different or broader range will be questioned; one covering less than you need will not authorize the rest.
3. Verify it names the correct ASN. The ASN that will actually originate the announcement — yours, or your upstream’s, depending on your setup. A wrong ASN is the most common reason a technically valid LOA fails to unblock a deployment.
4. Check the validity period against the lease term. An authorization that expires before the lease does creates a re-issuance dependency mid-deployment.
5. Confirm it comes from the registered holder. Letterhead and company details consistent with registry records, signed by an identifiable authorized person.
6. Confirm the re-issuance process. If you change upstream, change ASN, or need an additional LOA for a second provider, how fast can an updated document be produced? Deployments change; the authorization has to keep up.
7. Ask how it fits with ROA and route objects. An LOA alone is not enough — as the comparison above shows, ROA and IRR alignment matter too. A lessor that handles all three coherently is materially easier to deploy with than one that supplies a document and leaves the rest to you.

These questions cost nothing to ask before signing and are expensive to ask afterward. They are also, taken together, a reliable signal of lease quality: an arrangement that treats routing authorization as a defined deliverable is structured for production use, while one that treats it as an afterthought will surface that gap at the worst moment.

Common LOA Problems

Most LOA problems are not disputes about authorization — they are documents that are late, inaccurate, or expired. The recurring ones:

• Delivery delays. The most common and most costly. Every day without the document is a day the space cannot be announced, regardless of how ready everything else is.
• Wrong ASN. The LOA authorizes an ASN other than the one actually originating the announcement — often because the setup changed after the document was drafted, or because the lessee’s upstream arrangement was misunderstood.
• Wrong or imprecise prefixes. The document names a different block, a broader range than agreed, or is written ambiguously enough that the upstream will not act on it.
• Expired authorization. A validity period that lapsed, typically noticed when a provider re-checks documentation or when a new upstream is added mid-term.
• Unauthorized or unverifiable signatory. Signed by someone whose authority the upstream cannot confirm, or on documentation that does not tie back to the registered holder.
• Never addressed in the agreement. The lease is silent on LOA issuance entirely, leaving both timing and obligation undefined — which is how the delivery-delay problem usually begins.

All six are preventable at the agreement stage, which is why the verification list above matters more than any troubleshooting after the fact.

Practical Checklist

1. Confirm before signing that the agreement commits the holder to issue an LOA, with a defined delivery timeframe.
2. Obtain the LOA — or a written delivery guarantee — before payment.
3. Verify the exact prefixes match what you are leasing or acquiring.
4. Verify the ASN matches the one that will actually originate the announcement.
5. Check the validity period covers the full lease or deployment term.
6. Confirm the document is on the registered holder’s letterhead with matching company details and an identifiable authorized signatory.
7. Supply it in the format your upstream expects — PDF is the safe default; image formats are commonly rejected.
8. Confirm the re-issuance process and turnaround for upstream, ASN, or scope changes.
9. Align the LOA with your ROA and IRR route object so all three authorization records agree.
10. Keep a copy on file — additional providers, audits, and future changes will require it again.

Practical Note from i.lease

The LOA is a small document with disproportionate operational weight. It is not technically complex, it takes minutes to produce when someone is authorized and willing, and yet it is one of the most common reasons a leased or newly acquired block sits idle while a business pays for it. The reason is almost never a genuine dispute about authorization — it is that nobody defined, before the agreement was signed, who would issue the document, how quickly, and what it would say.

That makes LOA handling a useful proxy for the quality of an address arrangement overall. A lessor that issues a correct LOA promptly, names the right ASN and prefixes without three rounds of correction, re-issues quickly when your upstream changes, and keeps the ROA and route objects aligned alongside it is demonstrating exactly the operational discipline that production routing requires. One that treats the LOA as paperwork to sort out later will treat the rest of the relationship the same way. The document itself is trivial; the coordination behind it is not, and that coordination is what turns address space into working infrastructure. Whether you lease or acquire space outright, it is worth treating routing authorization as a defined deliverable with a timeframe — not an assumption.

Final Thoughts

A Letter of Authorization is the registered holder’s written permission for a named party to announce specified prefixes from a specified ASN. Upstream providers require it because they cannot verify from registry data alone that an announcer is authorized, and accepting an unauthorized announcement means participating in a hijack. The document names the holder, the authorized party and ASN, the exact prefixes, and the validity period, signed by someone with the authority to grant it — and it sits squarely on the critical path between having address space and being able to route it.

The distinction worth carrying away is what an LOA does and does not do. It authorizes announcement; it does not transfer ownership, change registration, or convey registry-level rights. In a lease, the space stays registered to the holder while the lessee’s right to announce derives from the authorization granted — which is precisely why the document exists and why it must come from the holder. Alongside the ROA that routers validate and the route object that filters consult, the LOA completes the set of records that turn a contractual right into an accepted announcement. Get all three aligned before deployment, verify the LOA’s details before you pay, and the space you have arranged becomes infrastructure you can actually use.

Also Read

What Is BGP Hijacking? How Route Hijacks Work, Famous Incidents, and How Networks Prevent Them

RPKI and ROA Explained: How Route Origin Authorization Protects Your IPv4 Prefixes

What Is BGP? How Border Gateway Protocol Turns IP Addresses into Reachable Services

Lease IP Address: IPv4 Leasing Guide

Frequently Asked Questions