SKNK Technical Guide
What Is a Letter of Authorization (LOA) in BGP?
When does a BGP route need a Letter of Authorization? What a LOA actually proves, how it differs from ROA and IRR, and when SKNK issues one.
Technical content
Written and maintained by Shikanoko NetworksA Letter of Authorization is one of the most misunderstood documents in routing. It gets requested, demanded, and conflated with everything from ROAs to lease contracts — so start with the sentence that clears up most of the confusion:
A LOA documents and evidences routing authorization. In many workflows, it is also the document that grants that authorization. It is not required for every BGP announcement.
You have an ASN and an IPv6 /48. You announce that /48 from your own ASN to a transit provider. Do you need a Letter of Authorization?
In most cases, no.
A LOA does not make BGP work, and BGP does not read one. A LOA is a document that tells another organisation: "the party controlling this prefix has authorized this organisation or ASN to use or originate it." It exists for the people in the process, not for the routers.
Definition Box: A Letter of Authorization (LOA) is a document issued by the party controlling an IP address resource, granting or confirming that another organisation or ASN is authorized to use or originate a specified prefix. It is an operational and onboarding document — not a BGP protocol object, not an RIR resource, and not a substitute for ROA, IRR records, or a contract.
A LOA documents and evidences routing authorization. In many workflows it grants that authorization — but it is not a file every announcement needs.
1. What Is a LOA?
A LOA — Letter of Authorization — is a written statement from the party that controls an IP prefix, saying that a particular organisation or ASN is allowed to use or originate it.
Some providers use the term "Letter of Agency" instead of "Letter of Authorization"; both are commonly abbreviated LOA in network operations.
Two things are worth saying up front:
- There is no single industry-wide technical format for a LOA. It is an operational and onboarding document, not a registry object. Two providers' LOAs can look completely different and still do the same job.
- A LOA is read by people. An engineer at a transit provider, a compliance team, or a network operations group reviews it. It is evidence, not a signal the network acts on automatically.
A useful LOA typically names the prefix, the authorized organisation, the authorized origin ASN, the controlling party, the permitted purpose, and the start date — and it states the expiry or revocation conditions, a verification contact, and a signature or other form of verification.
BGP does not read a LOA. Network operators do.
2. Why Do LOAs Exist?
Internet routing separates several roles that people often assume belong to one party:
- the resource holder — who controls the prefix in the registry;
- the resource user — who operates the addresses in practice;
- the origin ASN — the ASN that originates the route in BGP;
- the transit provider — who carries the route onward;
- the routing service provider — a DDoS, anycast, or managed-BGP provider, when one is involved.
None of these roles has to be the same organisation. A prefix can be controlled by one company, used by a second, originated by a third, and carried by a fourth.
A LOA exists to document one specific slice of that relationship: that the party controlling the prefix has authorized a particular organisation or ASN to use or originate it.
The authorization relationship can be separate from the route path itself; the LOA records the permission that connects them.
Notice what the diagram does not show: a LOA. That is deliberate. The authorization it describes is between the resource holder and the customer. The LOA is simply the document that puts that authorization into writing for a third party to review.
3. When Might You Need a LOA?
Most confusion about LOAs comes from treating them as an always-or-never thing. They are situational. The situations that keep coming up:
Leasing IPv4 address space
SKNK controls:
203.0.113.0/24
Customer operates:
AS65001
The customer wants to originate the /24 from AS65001. A third-party transit provider may reasonably ask: how do I know the holder of this /24 allows AS65001 to originate it? A LOA answers that question. This is one of the classic uses of a LOA, and it is the standard shape of IPv4 PA leasing.
Authorizing a third-party origin ASN
When the origin ASN belongs to a different organisation than the resource holder — a DDoS mitigation provider, an anycast network, a managed-BGP operator, a cloud platform, or a BYOIP platform — the route looks like this:
When another organisation originates the prefix, the authorization boundary becomes a real operational question.
The resources are yours; the origin ASN is someone else's. That split is exactly what a LOA is good at recording. The origin-AS portion of that authorization can also be expressed through RPKI. A resource holder can create a ROA authorizing a third-party ASN to originate the prefix.
DDoS mitigation and managed BGP
Scrubbing providers and managed-BGP services originate your prefix on your behalf. When they onboard you, they often want a document that ties your prefix to the origin ASN they will use.
BYOIP and cloud platforms
Bring-your-own-IP platforms let you announce or use your own addresses inside someone else's infrastructure. Onboarding usually requires proof that you control the addresses — and a LOA is frequently part of that proof.
Larger delegated IPv6 address space
A single standard /48 is one thing. A /44, a /40, or a /36 is a larger delegation with a wider authorization boundary, and it is more likely to be worth putting into a formal document.
A LOA does not replace RIPE NCC assignment requirements. PA assignments larger than a /48 still require an addressing or routing justification and are subject to SKNK review.
Provider onboarding and compliance
Here is the important caveat that keeps the article honest:
Even when a LOA is not technically required for routing, a specific provider may still require one as part of its own onboarding or compliance process.
Routing reality and a vendor's internal checklist are two different things. A LOA may be unnecessary for the route to work and still be required to open an account.
4. When Is a LOA Usually Unnecessary?
The simplest case is also the most common one for SKNK customers:
When the customer ASN originates its own prefix, there is usually no separate origin party for a LOA to authorize.
The customer gets an ASN sponsorship and an IPv6 PA /48, then originates the /48 from their own ASN. No new third-party origin ASN appears anywhere in that path.
In that model, there is usually nothing additional for a LOA to authorize:
There is no extra routing party here that needs a LOA to be authorized.
That wording matters. It is different from saying "we won't give you a LOA because it is unnecessary" — it explains why there is nothing for a LOA to do in the standard setup.
If you want a quick way to reason about it, ask one question: is the prefix being originated by your own customer ASN? If yes, a separate LOA is usually unnecessary. If no, the arrangement needs review, and the answer may involve a LOA, an IRR or ROA change, an agreement, or more than one of them.
5. Why Doesn't SKNK Provide a LOA with the Standard ASN + IPv6 /48 Service?
This is SKNK's policy section, and the logic follows directly from the last section.
A customer buys the standard service:
ASN Sponsorship
+
IPv6 PA /48
The typical use:
SKNK IPv6 PA
↓
Customer /48
↓
Customer ASN
↓
BGP
In this setup SKNK already knows the prefix, the customer, the customer's ASN, and the intended origin ASN — because the customer is expected to originate the assigned /48 from the ASN supplied or sponsored for that network. The relevant routing information can instead be represented through IRR and RPKI where applicable.
Therefore:
SKNK does not issue a separate LOA by default for the standard ASN + IPv6 PA /48 service.
The customer is expected to originate the assigned /48 from the ASN supplied or sponsored for that network. A separate document authorizing an unrelated origin ASN has nothing to authorize in the standard model.
6. "My Upstream Is a Third Party — Doesn't That Mean I Need a LOA?"
No, and this is the single most common misunderstanding.
Prefix: 2001:db8:1234::/48
Origin: AS65001
Transit: AS174
Transit providers like Cogent, Hurricane Electric, Arelion, or NTT are third parties, but they are transit — they propagate the route that AS65001 originates. They do not become the origin.
The AS_PATH for a route announced to AS174 and onward might look like:
174 65001
The origin — the rightmost ASN in the AS_PATH — is still AS65001. The transit provider carries the route; it does not originate it.
Using a third-party transit provider does not automatically mean a third party is originating your prefix.
Transit and origin are different roles. Using a third-party transit provider does not by itself create a LOA requirement, although a provider may still request one for route authorization or onboarding.
7. LOA vs. ROA
These two are confused constantly. They solve different problems.
| LOA | RPKI ROA | |
|---|---|---|
| Meaning | Letter of Authorization | Route Origin Authorization |
| Form | A document | A cryptographically signed RPKI object |
| Audience | Humans — providers, reviewers, compliance | RPKI validators and network operators |
| Purpose | Grants and/or documents an authorization relationship | Authorizes an origin ASN for a prefix |
| Cryptographically verifiable | Usually no | Yes |
| Used in BGP Origin Validation | No | Yes |
| Replaces a contract | No | No |
| Proves IP ownership | No | No |
A ROA states that a particular ASN is authorized to originate routes for a given prefix, and it can optionally set a maximum prefix length. It is the RPKI object that origin validation actually checks.
A LOA tells an operator what is permitted. A ROA makes that origin authorization cryptographically verifiable.
8. LOA vs. IRR Route Objects
One more layer down. An IRR route object records routing intent:
route6: 2001:db8:1234::/48
origin: AS65001
It says: AS65001 is the origin ASN for this IPv6 prefix. The RIPE Database route and route6 objects publish exactly this prefix-to-origin relationship, and many operators build their route filters from IRR data.
The three layers line up like this:
LOA, IRR, and ROA sit at different layers: human authorization, published routing intent, and cryptographically verifiable origin authorization.
Do not read the arrows as "one replaces the other." They solve different problems. A LOA documents a business relationship in prose. An IRR object publishes routing intent in a registry. A ROA makes the origin authorization verifiable by machines. They are not interchangeable mechanisms, although a particular provider may accept one or more of them for its own routing-validation workflow.
9. What a LOA Is Not
The quick way to keep a LOA in its lane is to list what it is not.
A LOA is not proof of IP ownership
Internet number resources are not ordinary property like a building or a domain. A LOA records a grant of permission; it does not establish who ultimately holds the resource.
A LOA is not an RIR assignment
A LOA does not create any object in the RIPE Database. It does not register an inetnum or inet6num.
A LOA is not a ROA
One word apart, completely different mechanisms. A LOA is a document for humans; a ROA is a signed object for validators.
A LOA is not a BGP requirement
The BGP protocol itself does not require a LOA. A session can be established and routes can be advertised without one, although a provider's routing policy may still reject the prefix.
A LOA is not an IPv4 lease agreement
This distinction matters for anyone leasing address space. A lease agreement defines the commercial relationship — fees, term, acceptable use, abuse handling, termination, liability, and return of resources. A LOA carries only the specific authorization to use or originate a prefix. They are two different documents, and for an IPv4 lease you should expect both to exist side by side.
10. What Should a LOA Contain?
If you are drafting or reviewing one, a complete LOA names:
Authorizing organisation
Customer / authorized organisation
IP prefix(es)
Authorized ASN(s)
Permitted routing purpose
Effective date
Expiry date, if applicable
Revocation terms
Reference / agreement number
Verification contact
Authorized signature
Two clauses are worth insisting on, because they protect the resource holder:
No transfer of ownership. This authorization does not transfer ownership, registration rights, or control of the underlying Internet number resource.
Revocable. Authorization ends when the underlying service or lease ends.
11. When Does SKNK Provide a LOA?
This is the commercial rule, in the shape customers actually need:
| Service | LOA |
|---|---|
| ASN + standard IPv6 PA /48 | Not issued by default |
| Larger or additional IPv6 PA | Available where operationally required, subject to assignment eligibility and review |
| IPv4 PA leasing | Available |
| Third-party origin ASN | Available subject to review |
| DDoS / BYOIP / special routing | Available subject to review |
For IPv4 leasing, the full chain comes together as several coordinated pieces: an IPv4 lease agreement, a LOA, the IRR route object, and the RPKI ROA.
12. What If My Provider Asks for a LOA?
Do not treat this as a dead end. The useful move is to send SKNK the routing arrangement and let it be reviewed.
Send:
Prefix
Requested origin ASN
Third-party provider
Purpose
Required wording, if any
SKNK then checks whether the arrangement is already covered by an existing assignment and determines what is actually needed.
A routing request can be reviewed once and routed to the document or registry change that actually fits the arrangement.
This turns what could be a back-and-forth support ticket into a single, reviewable request.
FAQ
Do I need a LOA to announce my SKNK IPv6 /48?
For the standard ASN + PA /48 service: no separate LOA is normally provided or required. You originate the assigned prefix from your own ASN.
Does my transit provider need to be listed on a LOA?
For standard transit, your provider does not need to be listed as the authorized origin ASN. It propagates the route but does not originate it; a provider may still request a LOA as evidence of route authorization or onboarding.
Can another ASN originate my prefix?
Only with prior authorization, and the routing records need to match. That usually means a LOA plus matching IRR and RPKI configuration.
Is a LOA the same as a ROA?
No. A LOA is a document for humans; a ROA is a cryptographically signed object that origin validation checks.
Does a LOA prove I own the IP addresses?
No. It records an authorization, not ownership or registration.
Can SKNK provide a LOA if my provider specifically requests one?
For larger IPv6 PA, IPv4 PA leasing, third-party origin, or other special routing arrangements, a LOA can be provided based on the routing arrangement and SKNK's review.
Conclusion
Not every route needs a letter.
A LOA is useful when routing authority has to be demonstrated between separate parties. It is not a prerequisite attached to every BGP announcement.
With SKNK's standard ASN + IPv6 PA /48 service, the expected model is simple: the customer originates the assigned prefix from their own ASN, so a separate LOA is not issued by default. More complex arrangements — IPv4 leasing, larger IPv6 delegations, or third-party origination — can be supported with additional authorization where required.
Key Takeaways
- A LOA documents and evidences routing authorization — and in many workflows it is the document that grants it; it is not required for every announcement.
- BGP does not read a LOA — network operators and onboarding teams do.
- A LOA, an IRR route object, and a ROA solve different problems; a provider may accept one or a combination of them for routing validation.
- Transit is not origin: using a third-party transit provider does not mean a third party is originating your prefix.
- SKNK does not issue a separate LOA by default for the standard ASN + IPv6 PA /48 service; LOAs are available for IPv4 leasing, larger IPv6 PA, and third-party origin arrangements.
In One Sentence
A LOA documents that a prefix's controller has authorized a specific ASN to originate it — it is not a BGP requirement, not proof of ownership, and not a ROA — so the standard SKNK ASN + IPv6 /48 service needs none by default, while leasing, third-party origination, and other special routing arrangements are common cases where one may be required.
Continue Reading
- What Is a ROA? — the cryptographically signed object that authorizes an origin ASN, and why
maxLengthmatters. - What Is an IRR Route Object? — the registry record for prefix-to-origin routing intent.
- RPKI vs. IRR — the two systems that describe routing, and where each fits.
- How to Rent IPv4 Addresses — the leasing context where a LOA most often appears.
- How to Announce an IPv6 /48 via BGP — the origin → authorization → acceptance chain in IPv6.
- SKNK IPv4 Leasing — how the lease agreement, LOA, IRR, and ROA fit together.