What is an LOA in networking? The short answer
A Letter of Authorization (LOA) is a recipient-specific document in which the party with authority over an IP prefix authorizes a named party or network to announce that prefix under a specified ASN. An upstream, hosting provider, cloud platform, or mitigation service may request it before accepting or configuring an announcement.
An LOA is human-readable evidence. It is not a universal Internet standard, a registry transfer, a lease contract, a Route Origin Authorization (ROA), an IRR route object, or proof that every network will accept the route. The receiving provider's current process determines whether an LOA is required, what it must contain, and how it is reviewed.
What an LOA authorizes
The document connects an operational routing request to the party that can grant permission. In a leased IPv4 arrangement, the registered holder may authorize the lessee, a transit provider, a cloud platform, or another named operator to announce the exact leased prefix. The lease and the registry record remain separate evidence: an LOA does not change the registered holder or transfer registry rights.
The authorization should match the deployment that the recipient will configure. At minimum, check the parties, the exact prefix, the origin ASN or announced ASN, the purpose, the effective period, the signatory, and a contact that the recipient can verify. Some providers use their own template or automated ownership-validation flow, so a document that works for one recipient may not satisfy another.
When do providers request an LOA?
An LOA is commonly requested when the announcing party is different from the registered holder, but there is no global rule that makes one document mandatory for every route. The recipient's onboarding and filtering policy controls the requirement.
- Leased IPv4 announced by a customer: an upstream may ask the holder to authorize the customer's ASN or the provider's ASN before accepting the route.
- Provider or data centre announcement: the operator may need evidence that it can announce a customer's or lessor's prefix from its own network.
- BYOIP onboarding: a cloud, edge, or DDoS-mitigation platform may require an LOA, a signed authorization message, RPKI, reverse DNS, or another combination of ownership and routing evidence.
- Provider or ASN changes: a new upstream or origin ASN may require a new document even when an earlier LOA was accepted for a different deployment.
Ask the intended recipient for its current requirements before signing or paying. Cloudflare documents an LOA for its BYOIP flow, while AWS and Google Cloud document other cryptographic or RPKI-based authorization steps for their own products. Those examples demonstrate why a provider-specific checklist is more reliable than a universal LOA template.
What should an LOA contain?
| Detail | What to verify | Why it matters |
|---|---|---|
| Authorizing party | The holder or authorized representative is identified with organization details that the recipient can reconcile with registry or account records. | The recipient needs a credible authority chain, not only a statement from the party that wants to announce. |
| Authorized party | The customer, provider, platform, or other named operator is identified, including the relationship when the recipient requires it. | A broad permission to “any provider” may not match a recipient's provisioning controls. |
| Exact prefix | Every IPv4 or IPv6 CIDR is written precisely, including any approved more-specific prefixes. | A different, broader, or incomplete range can leave the intended announcement outside the documented scope. |
| Origin ASN | The ASN that will actually originate the route is named, or the document follows the recipient's approved model when the ASN is supplied later. | A valid signature does not make a route acceptable when the origin does not match the recipient's filter. |
| Purpose and period | The intended announcement or service, start date, expiry, and relationship to the lease or service term are clear. | Authorization can be limited in time or scope and may need re-issuance after a change. |
| Signer and verification contact | The signatory's name, role, signature method, and contact details meet the recipient's current format requirements. | The recipient must be able to verify that the signer can grant the stated permission. |
Letterhead, PDF delivery, wet or digital signatures, stamps, and contact fields are recipient-specific requirements. Treat the intended upstream or platform's published instructions as the acceptance criterion and keep the final document with the lease and change record.
LOA vs contract, ROA, IRR, and BGP
These artifacts answer different questions. Aligning them reduces avoidable delays, but one artifact cannot replace the others or guarantee reachability.
| Artifact | Primary question | What it does not prove by itself |
|---|---|---|
| Lease or service contract | What rights, term, duties, fees, renewal, return, and abuse responsibilities did the parties agree? | That an upstream has configured or accepted a route. |
| LOA | Has the holder or authorized party given this named recipient permission for this routing use? | Registry transfer, cryptographic origin validity, or acceptance by every network. |
| IRR route object | What prefix and origin ASN are published as routing-policy data for operators that use the relevant registry? | Current contractual authority, cryptographic validation, or use by every filtering system. |
| RPKI ROA | Which origin ASN and maximum prefix length does the validated RPKI object authorize? | The complete AS path, the lease terms, an LOA, or data-plane reachability. |
| Observed BGP route | What prefix, origin, path, and attributes did one observer receive at a particular time? | Authority, universal visibility, return-path health, or application availability. |
RFC 9582 defines a ROA as a digitally signed object that lets a relying party verify that an address-space holder authorized an AS to originate routes to specified prefixes. That is a different mechanism from the human document an upstream may request. Route Origin Validation also does not validate the entire AS path or the application behind the route.
LOA workflow for leased IPv4
- Define the deployment. Record the exact CIDR, intended origin ASN, announcing provider, more-specific policy, service or platform, start date, lease term, and rollback owner.
- Ask the recipient what it accepts. Confirm whether it requires an LOA, its own template, a signed API message, RPKI, IRR data, reverse DNS, proof of control, or a combination.
- Confirm the holder's authority. Match the contracting party and signatory to the registry and account evidence that the recipient will review. A lessee should not create an LOA that purports to come from the holder.
- Draft against the actual route. Use the exact prefix and the ASN that will originate it. If the provider will announce from its ASN, name that ASN; if the plan may change, document the re-issuance path.
- Align machine-readable records. Coordinate the applicable IRR route object and ROA with the same prefix and origin. Remove or replace stale records through their responsible operators.
- Submit and verify acceptance. Keep the recipient's ticket or onboarding result, then confirm the route at the upstream and independent observation points. A submitted document is not evidence that the router has accepted the route.
- Operate the expiry and exit. Monitor authorization expiry, lease renewal, origin changes, abuse contacts, route withdrawal, and cleanup of LOA, IRR, and RPKI records when the arrangement ends.
Do not promise a propagation time from the LOA alone. Each autonomous system applies its own filters and policy, and a route can be accepted by one provider while remaining unavailable elsewhere.
What to verify before paying for leased space
- Ask who issues the LOA, when it will be delivered, whether the recipient's template is required, and who pays for re-issuance after an ASN or upstream change.
- Compare the prefix, origin ASN, holder name, dates, and authorized party across the contract, LOA, registry evidence, IRR plan, and ROA plan.
- Check whether the lease covers routing coordination, reverse DNS, abuse handling, geofeed or geolocation requests, RPKI and IRR changes, monitoring, and withdrawal.
- Define what happens when a recipient rejects the document, the route is filtered, the term expires, the holder becomes unavailable, or the prefix must be returned.
- Keep dated copies of the document and external validation results. Reputation, geolocation, route visibility, and provider policy can change after activation.
Common LOA failures
| Symptom | Likely mismatch | Next check |
|---|---|---|
| Upstream rejects the request | Missing document, unsupported format, unverifiable signer, or an LOA that does not meet the provider's process. | Read the recipient's current requirement and ask which field or evidence failed. |
| The prefix is outside the filter | The CIDR or approved more-specific differs from the document or the provider ticket. | Compare the exact route, LOA, IRR object, and provider filter. |
| The route is RPKI Invalid | The ROA origin ASN or maximum length does not cover the announcement. | Inspect the validated ROA and the actual BGP origin; an LOA cannot change RPKI state. |
| One provider sees the route and another does not | Local policy, stale filters, propagation, peering, or a different acceptance requirement. | Compare independent collectors, provider advertisements, and data-plane tests at the same observation time. |
| A renewal or provider change stalls | The LOA expired or names the previous ASN, provider, scope, or term. | Use the documented re-issuance and withdrawal plan before changing the route. |
LOA deployment checklist
- Write down the recipient, prefix, origin ASN, purpose, dates, holder, and accountable operator.
- Obtain the recipient's current LOA or authorization requirements in writing.
- Verify the signer and holder relationship before accepting the document.
- Compare all fields with the lease, registry evidence, IRR plan, and ROA plan.
- Record the provider's acceptance result and the exact change window.
- Observe the route, RPKI state, and representative application traffic after activation.
- Schedule renewal, re-issuance, withdrawal, and record cleanup before the term ends.
Put a leased prefix into service
If the prefix, origin ASN, authorization path, and acceptance criteria are now defined, review managed IPv4 leasing for a service-led delivery path. For registry, IRR, RPKI, and routing coordination around the handoff, review registry coordination or discuss the resource-management requirement with i.lease. Availability, counterparties, provider acceptance, propagation, and reachability still require case-specific verification.
LOA FAQs
What is an LOA in networking?
An LOA, or Letter of Authorization, is a recipient-specific document that authorizes a named party or network to announce specified IP prefixes under a specified ASN. It is human-readable evidence and its format and necessity depend on the receiving provider or platform.
Is an LOA the same as a ROA?
No. An LOA is a document reviewed by people or a provider workflow. A ROA is a digitally signed RPKI object used for origin validation. They can support the same deployment, but they serve different systems and neither one replaces the other when both are required.
Who issues an LOA for leased IPv4?
The holder or an authorized representative should issue it for the routing use the recipient is reviewing. A lessee can request or submit the document, but should not create a document that falsely represents the holder's authorization.
Do I always need an LOA to announce leased IP addresses?
No universal rule applies. Many upstreams request holder authorization when the announcer differs from the registered holder, while some platforms use signed authorization messages, RPKI, ownership validation, or their own workflow. Ask the intended recipient before deployment.
Does an LOA transfer ownership of an IP prefix?
No. It documents permission for a routing use. It does not change the registry record, transfer the prefix, or grant registry-level rights. Ownership or registration changes follow the applicable RIR process and separate agreements.
What information should an LOA include?
Usually the authorizing holder, authorized party, exact prefix, origin ASN or approved announcing model, purpose, effective period, signatory, and verification contact. The recipient may require a specific template, file format, signature method, or additional evidence.
Can an LOA make a BGP route reachable?
No. It may satisfy one provider's authorization check, but reachability also depends on the provider's filters, IRR and RPKI state when used, BGP propagation, return routing, DNS, firewalls, and the application.
What should happen when an LOA or lease expires?
Follow the agreed renewal or withdrawal plan. Confirm whether the route must be withdrawn, update or remove related IRR and ROA records through the responsible operators, and retain evidence of the final state. Do not continue announcing a prefix after authorization has ended.
