Blog
The letter of authorization (LOA): what it is and who signs it
A letter of authorization (LOA) is a signed statement from the holder of an address block that a named network may announce it. Upstream providers, exchanges and many hosting and cloud providers ask for one before they accept a prefix they have not seen from you before. It is the human-readable half of an authorization whose machine-readable half is the ROA and the route object, and those that ask for it usually want both.
What an LOA contains
There is no single official form, but every good LOA answers the same questions:
- The prefix, exactly as it will be announced: 203.0.113.0/24.
- The holder, the organization the registry shows for the block, with its address.
- Who may announce it: the customer's organization and the AS number that will originate the route.
- Through whom: the upstream or provider the letter is addressed to, and its ASN where relevant.
- How long: a start date and an end date, or "for the duration of the lease".
- A signature from someone who can bind the holder, with a contact for questions.
A plain example, with documentation values:
14 October 2026
To: Example Transit Ltd (AS64511)
Letter of authorization for 203.0.113.0/24
Example Holder B.V., the registered holder of 203.0.113.0/24, authorizes
Example Customer GmbH to announce 203.0.113.0/24 from AS64500 through
Example Transit Ltd, from 14 October 2026 until 13 October 2027.
Signed for Example Holder B.V., name and position, contact addressWho asks for one
- Transit providers and exchanges, before they add the prefix to the filters on your session.
- Hosting and cloud providers that accept your space. Vultr asks for an LOA upload with a BGP request, Leaseweb wants one for every block, signed by the holder, and Cloudflare can generate its own. AWS, Azure and Google Cloud ask for none: they check the ROA and a certificate in the registry record, or at Google a PTR record. Each provider guide says which (BYOIP guides).
- DDoS protection services that announce your prefix during an attack.
LOA, ROA and route object
They answer the same question for different readers, which is why you usually need all three.
| Written by | Read by | Checked | |
|---|---|---|---|
| LOA | The holder | People at your upstream or provider | By hand, against the registry record |
| ROA | The holder, in the registry's RPKI | Routers, through validators | Automatically, on every route (RPKI and ROAs) |
| Route object | The holder, or with its authorization | Prefix filters built from routing registries | Automatically, when filters are rebuilt (route objects) |
An LOA without a matching ROA can still fail: if a ROA exists for the block and names another ASN, your announcement comes back invalid however good the letter is.
Mistakes that get an LOA rejected
- Signed by someone other than the registered holder. Providers compare the letter with the registry record. A reseller's letter for space it does not hold is not enough.
- The wrong ASN, or no ASN at all.
- Expired. Some providers check the dates, so a letter that ran out last month stops a change today.
- A larger block than you use. Name the prefix you will announce, not the allocation it comes from.
If you lease the block
The holder writes the LOA, because only the holder can. With a lease that is the lessor. Ask for it at the start, naming the upstream or provider and the ASN, and ask for a new one when either changes.
Where RTM Networks fits
For space leased from us, we issue the LOA whenever you need one, addressed to your upstream or provider and naming your ASN, along with the ROA and the route object that go with it (lease IPv4).
Contact
Advies over uw eigen situatie?
Dit artikel is algemeen; uw netwerk niet. Vertel ons waarmee u werkt, dan kijken wij er goed naar. Wij reageren meestal in 1-3 kantooruren.
