IPv4 Letter of Authorization: Scope and Template
An IPv4 letter of authorization (LOA) records permission for a named party to announce or carry a specified prefix. Its recipient checks the signer’s authority and the requested scope. It is separate from registry registration, an IRR route object and an RPKI authorization.
| Document | What it establishes | What it does not do |
|---|---|---|
| Routing LOA | Permission for the stated announcement or transit arrangement | Complete a registry transfer or create a ROA |
| Registry transfer agreement or authorization form | The parties’ request and authority for the applicable registry procedure | Automatically authorize a new BGP origin at an upstream |
Check the document’s recipient and stated action rather than relying on its title alone. The transfer-document checklist covers registry paperwork.
| Item | Include or verify |
|---|---|
| Resource | Exact IPv4 prefixes; avoid an unspecified covering block |
| Issuer | Resource holder’s legal name and registry organization reference |
| Origin | ASN that will originate each prefix |
| Recipient | Provider name and ASN, with its role stated explicitly |
| Scope | Origination, transit acceptance, or both, as agreed |
| Validity | Issue date, intended effective period and change reference |
| Signer | Name, role, signature and independently verifiable contact |
This checklist was checked against provider documentation on 15 November 2026. It is a preparation aid, not a universal provider form. For example, Vultr’s BGP access procedure requests an uploaded LOA for customer address space. Obtain the recipient’s current requirements before signing.
Separate the origin from the upstream
Suppose the holder authorizes your AS64496 to originate 192.0.2.0/24. Transit providers AS64497 and AS64498 carry that route. Keep the originating network’s identity separate from the providers propagating its route.
Ask each provider which permission its LOA must establish. A letter addressed to A may not satisfy B. A second document or separately addressed copy can be required even while the origin remains unchanged.
If a hosting provider will originate the prefix under its own ASN instead, state that arrangement explicitly. Do not copy a provider-origin template into a customer-origin deployment without changing the scope. Likewise, an upstream ASN does not belong in the ROA merely because it carries your announcement.
Establish the signer’s authority
Compare the issuer with the current WHOIS or RDAP record. Registry data helps identify the holder; it does not establish that any person using the organization’s name can sign.
Use an independently obtained holder contact to confirm the signer and any delegation. If the registered holder, lessor and signer differ, explain the relationship and supply the evidence the provider requests. Avoid relying only on a telephone number or email address printed in the submitted letter.
For leased addresses, agree who issues, renews and revokes the document. Confirm these responsibilities when arranging leased IPv4 space; this guide does not establish a particular supplier’s document service or turnaround.
Download and adapt the template
Download the editable LOA preparation template.
The file uses placeholders rather than real resources. It provides two alternative scope clauses: customer origination through a provider, or origination by the provider itself. Keep the applicable clause, remove the alternative, and have the authorized issuer review the result.
Before sending it:
- Obtain the recipient’s form, signature and evidence requirements.
- Match every prefix and origin ASN to the agreed routing plan.
- Identify each provider’s role without granting unrelated permissions.
- Confirm the signer and the document’s effective period.
- Save the signed version and obtain explicit acceptance from each recipient.
The unsigned template grants no permission. An accepted LOA still needs the separate routing records and checks in the prefix-announcement runbook.
Reissue and withdrawal checks
Review the LOA when the prefix, holder, origin, provider or scope changes. Ask whether the recipient requires a new signature or a new validity period. Keep the superseded version with its replacement reference so the NOC can identify the applicable authorization.
At the end of an arrangement, coordinate the document withdrawal with BGP withdrawal and the holder’s record changes. Sending a cancellation email does not itself withdraw a route, delete an IRR object or remove a ROA.