A Letter of Authorization, commonly called an **LOA**, is a document through which an IP address holder or authorized resource controller gives another organization permission to perform a specific network operation.
In IPv4 deployment, an LOA is most commonly used to confirm that a designated Autonomous System Number can announce a specified IPv4 prefix through the Border Gateway Protocol.
For example, an organization may control an IPv4 block but use a cloud provider, hosting company, Internet service provider, or managed network operator to announce it. The LOA documents the permission connecting the resource, the authorized network, and the intended routing activity.
A typical IPv4 LOA identifies:
- The organization granting permission
- The organization receiving permission
- The relevant IPv4 prefixes
- The authorized origin ASN
- The permitted activity
- The effective and expiry dates
- The authorized signatory
- Contact details for verification
An LOA supports commercial and operational verification. It does not replace accurate registry records, secure BGP configuration, Internet Routing Registry objects, or an RPKI Route Origin Authorization.
Why IPv4 deployment requires authorization
The Internet consists of thousands of independently operated networks. Each network may use an Autonomous System Number, or ASN, to exchange routing information with other networks.
When an organization announces an IPv4 prefix through BGP, other operators must decide whether to accept and propagate that route.
This raises a basic question:
Does the network announcing the prefix have permission to do so?
The organization using an IPv4 block is not always the organization listed as its resource holder. Common arrangements include:
- A hosting provider announcing customer-controlled IPv4 space
- A cloud platform supporting Bring Your Own IP deployment
- A lessee announcing IPv4 addresses obtained through a lease
- A customer using a separate transit provider
- A managed network operator announcing resources for a client
- A business moving its IP addresses to new infrastructure
- A multihomed network using more than one upstream provider
In these cases, the resource holder, customer, origin ASN, hosting provider, and transit provider may be different entities.
The LOA creates a written connection between those parties. It allows the receiving provider to understand who granted permission, what resources are covered, and which network activity has been authorized.
What does LOA mean?
LOA is commonly expanded as:
- Letter of Authorization
- Letter of Authority
“Letter of Agency” may also appear in some provider, transfer, or leasing contexts.
There is no single universal title or format used by every ISP, data centre, cloud platform, Regional Internet Registry, or jurisdiction. The document’s substance is therefore more important than its name.
A useful LOA should answer four questions:
1. Who is granting authorization?
2. Who is receiving authorization?
3. Which IPv4 resources are covered?
4. What action is permitted?
If any of these points is unclear, the receiving network may request additional evidence before accepting the deployment.
How does an IPv4 LOA work?
An LOA normally forms part of a broader onboarding and routing-verification process.
The process may follow these steps:
1. The resource holder or authorized controller prepares the LOA.
2. The document identifies the IPv4 prefix and intended origin ASN.
3. The customer submits the LOA to its hosting, cloud, or transit provider.
4. The provider verifies the document and supporting records.
5. Required IRR and RPKI information is reviewed or updated.
6. The provider approves the prefix for deployment.
7. The network announces the prefix through BGP.
8. Routing, reachability, and validation status are monitored.
An LOA does not send a BGP announcement or automatically cause other networks to accept a route. It provides documentary authorization for the technical process.
Providers may apply different verification standards. Some require a signed document, while others use an authenticated portal, a specific template, direct confirmation from the resource holder, or additional contractual records.
When is an IPv4 LOA required?
Whether an LOA is required depends on the provider and deployment model. It is commonly requested in the following situations.
IPv4 leasing
A business may lease IPv4 addresses and announce them from its own ASN.
The lessor or authorized controller can issue an LOA confirming that the lessee’s network is permitted to originate the relevant prefixes.
LARUS provides first-party IPv4 leasing and deployment support, including operational controls related to routing validity, RPKI and ROA readiness, reverse DNS, reputation, geolocation, and support.
In a leasing arrangement, the LOA should align with the lease term, authorized ASN, permitted use, and termination process.
Bring Your Own IP
Bring Your Own IP, commonly called BYOIP, allows an organization to deploy address space it already controls within another provider’s infrastructure.
A cloud or hosting platform may request an LOA before allowing the prefix to be advertised from its network.
The provider may also request:
- Registry information
- An RPKI ROA
- An IRR route object
- Proof of organizational authority
- Validation through DNS or another technical method
Transit-provider onboarding
An Internet transit provider may request an LOA before accepting a customer’s IPv4 announcement.
This helps the provider confirm that the customer has permission to use the prefix and reduces the risk of propagating an unauthorized route.
Multihoming
A multihomed network connects to more than one upstream provider.
Each provider may require documentation confirming that the customer’s ASN is authorized to announce the relevant prefixes.
The LOA should be consistent with the intended routing policy and any RPKI ROAs.
Cloud or data-centre migration
An organization moving services to a new cloud platform, data centre, or hosting provider may need to authorize a new network to announce its existing IPv4 space.
The migration plan should coordinate:
- Old and new providers
- Origin ASNs
- LOA dates
- ROA changes
- IRR updates
- BGP announcements
- Withdrawal of obsolete authorization
Managed network services
A resource holder may authorize a managed service provider to perform routing, reverse-DNS, or related network operations.
The LOA should state the specific activities the provider may perform rather than granting unrestricted authority.
Emergency continuity
During an outage or infrastructure failure, a resource holder may need to authorize an alternative network temporarily.
Emergency authorization should still identify the precise prefixes, ASN, effective period, and revocation process.
What should an IPv4 LOA contain?
There is no universal LOA template, but the following information is commonly required.
1. Date of issue
The document should state when it was issued.
The date helps the receiving provider determine whether the authorization is current and connected to the planned deployment.
2. Authorizing organization
The LOA should include the full legal name of the organization granting permission.
Where possible, this name should align with the relevant registry, contractual, or corporate records.
If a parent company, subsidiary, lessor, agent, or service provider is involved, the relationship should be explained clearly.
3. Authorized organization
The document should identify the network or service provider receiving authorization.
This may be:
- An ISP
- A transit provider
- A cloud platform
- A hosting company
- A data centre
- A lessee
- A managed network operator
4. IPv4 prefixes
Every authorized prefix should be written accurately in CIDR notation.
Examples include:
- `192.0.2.0/24`
- `198.51.100.0/24`
The address and prefix length must be checked carefully. A `/23` and one of its component `/24` prefixes are not interchangeable.
5. Origin ASN
The LOA should state which ASN is permitted to originate the prefix through BGP.
If more than one ASN is permitted, the intended routing arrangement should be explained. The corresponding RPKI configuration may require separate ROAs for different origin ASNs.
6. Scope of authorization
The document should describe the actions being authorized.
These may include permission to:
- Originate the prefix through BGP
- Accept and propagate the route
- Provide Internet transit
- Manage reverse DNS
- Create agreed IRR objects
- Support a defined migration
- Perform specified operational tasks
Clear scope reduces uncertainty between routing permission, resource use, administration, and ownership.
7. Effective and expiry dates
An LOA may remain valid:
- For a fixed period
- For the duration of a service agreement
- Until a specified date
- Until revoked in writing
Time limits are particularly important for leased IPv4 addresses, temporary migrations, and emergency deployments.
8. Authorized signatory
The LOA should identify the person approving the authorization.
Relevant information may include:
- Full name
- Job title
- Organization
- Signature or approved electronic authentication
- Business email address
- Telephone number
The receiving provider may compare this information with corporate, contractual, or registry records.
9. Verification contact
The document may include a separate contact through which the receiving provider can verify the authorization.
The verification channel should ideally be independent of the person submitting the LOA.
10. Revocation conditions
The LOA should explain how the authorization can be withdrawn.
Clear revocation procedures help prevent an outdated document from remaining in use after a lease, migration, or provider relationship ends.
What an LOA does not prove
An LOA is useful evidence, but it has limits.
A conventional signed document does not automatically prove that:
- The signatory controls the IPv4 block
- The organization has a complete legal claim to the resource
- The document has not been modified
- The authorization remains current
- The route is configured correctly
- The IPv4 block has a clean operational reputation
- The relevant RIR recognizes the commercial arrangement
- The announcement will be accepted globally
- A corresponding RPKI ROA exists
An LOA should therefore be treated as one part of a layered authorization process.
Responsible providers compare the document with other technical, registry, and commercial information before allowing deployment.
How is an IPv4 LOA verified?
Verification practices differ among providers, but several sources are commonly reviewed.
Regional Internet Registry information
The provider may review information published by the relevant RIR:
- ARIN
- RIPE NCC
- APNIC
- AFRINIC
- LACNIC
LARUS Foundation’s educational guide to [the role of RIRs in Internet governance](https://www.larus.foundation/post/the-role-of-rirs-in-internet-governance) explains how these organizations support number-resource registration, policy processes, routing-security services, training, and public databases.
Registry information may help identify the organization associated with a prefix, but it may not describe every leasing, hosting, or managed-service relationship.
RDAP and WHOIS records
Registration Data Access Protocol and WHOIS services provide information about Internet number resources and associated organizations.
Providers may compare the LOA with:
- Organization names
- Administrative contacts
- Technical contacts
- Resource status
- Registration dates
- Public remarks
These records can become outdated, so they should not always be treated as the only evidence.
RPKI and Route Origin Authorization
A provider may check whether a valid ROA authorizes the proposed origin ASN.
The Internet Engineering Task Force defines a ROA as a digitally signed object through which an address-block holder authorizes an AS to originate one or more prefixes. The current standard is [RFC 9582](https://www.ietf.org/rfc/rfc9582.html).
APNIC also provides an accessible guide to [RPKI, ROAs, and Route Origin Validation](https://www.apnic.net/community/security/resource-certification/).
Internet Routing Registry information
The provider may review IRR route objects linking the IPv4 prefix with an origin ASN.
IRR databases support routing-policy publication, although their authority, validation methods, and data quality can vary.
BGP routing history
Existing and historical routing data may help determine:
- Which ASN previously originated the prefix
- Whether the block is currently announced
- Whether conflicting origins exist
- Whether unexpected more-specific routes have appeared
A change in routing history does not automatically indicate misuse, but it may require explanation.
Commercial documentation
In a leasing or managed-service arrangement, the provider may request a lease agreement, service contract, or other record connecting the resource controller with the customer.
Direct verification
The receiving provider may contact the resource holder through independently obtained contact information.
Direct verification helps reduce the risk of relying on an altered or impersonated communication.
LOA vs ROA: what is the difference?
LOA and ROA sound similar, but they are different forms of authorization.
| Feature | LOA | ROA |
|---|---|---|
| Full term | Letter of Authorization | Route Origin Authorization |
| Form | Commercial or operational document | Cryptographically signed RPKI object |
| Main purpose | Communicates permission to a provider | Authorizes an ASN to originate specific prefixes |
| Verification | Manual or provider-specific | Cryptographic validation |
| Standardization | No universal format | Defined by an IETF standard |
| Main users | Resource holders, customers, and providers | RPKI validators and network operators |
| Directly sends a BGP route | No | No |
| Replaces the other | No | No |
An LOA tells a provider that a network has permission to perform an agreed action.
A ROA provides cryptographically verifiable information about which ASN is authorized to originate the prefix.
A production deployment may require both.
LOA vs IRR route object
An IRR route object is structured routing-policy data that usually connects an IP prefix with an origin ASN.
Network operators may use these objects to create route filters.
An LOA differs because it is a document exchanged between parties. It records commercial or operational permission rather than functioning as a routing-policy database object.
A provider may therefore require several aligned elements:
- A valid LOA
- A correct IRR route object
- An appropriate RPKI ROA
- Consistent registry information
- Completed internal verification
Several consistent sources provide stronger assurance than one document alone.
LOA vs IPv4 lease agreement
An LOA and an IPv4 lease agreement also serve different purposes.
A lease agreement defines the wider commercial relationship, which may include:
- Price
- Lease term
- Acceptable use
- Payment
- Renewal
- Support
- Abuse handling
- Termination
- Liability
- Return of resources
The LOA provides narrower operational permission, such as authorization for a specified ASN to announce a specified prefix.
A lease can exist without clearly documenting routing permission. An LOA helps translate the commercial relationship into a network action.
The two documents should be consistent, particularly regarding the parties, prefixes, duration, permitted use, and termination date.
Common mistakes in IPv4 LOAs
Incorrect origin ASN
The authorized ASN must match the intended BGP announcement.
Confusion can arise when the customer, hosting provider, and transit provider each operate different ASNs.
Incorrect prefix or prefix length
A typographical error can delay deployment or authorize an unintended resource. Prefixes should be copied from verified records and reviewed by a second person.
Unclear organizational authority
A customer may submit an LOA even though another organization controls the resource. The relationship between holder, lessor, lessee, and network operator should be documented.
Missing authorization period
An open-ended document may remain in circulation after the commercial relationship ends.
A defined expiry date or revocation condition reduces this risk.
Unverifiable contact information
A personal email address or inactive corporate domain can make verification difficult. Current business contact information is preferable.
Treating an LOA as a security guarantee
A signed PDF does not provide cryptographic route validation. RPKI, secure account access, routing controls, and monitoring remain necessary.
Failure to revoke old authorization
When a customer changes providers or a lease ends, obsolete LOAs and related routing records should be reviewed.
This may include:
- Old IRR objects
- Previous ROAs
- BGP announcements
- Reverse-DNS authority
- Provider access
- Internal asset records
Security risks associated with LOAs
Traditional LOAs are frequently verified through manual processes. This can create risks such as:
- Forged signatures
- Modified prefixes
- Impersonated contacts
- Reuse of expired documents
- Authorization by former employees
- Confusion between related companies
- Inconsistent records
- Delayed revocation
ARIN has discussed the limitations of paper-based authorization and the potential for RPKI Signed Checklists to provide stronger verification.
Cryptographic verification may improve trust in authorization workflows over time. Until such methods are widely supported, organizations can reduce risk through careful document management and layered verification.
Best practices for organizations issuing an LOA
Resource holders and authorized controllers should:
- Use a controlled LOA process
- Assign a unique reference number
- List exact prefixes and ASNs
- Use approved corporate signatories
- Include effective and expiry dates
- Define the scope of permission
- Maintain an authorization register
- Store signed records securely
- Confirm acceptance with the provider
- Align LOA, IRR, and RPKI information
- Revoke obsolete authorization promptly
- Monitor routing after deployment
An authorization register should record:
- Who issued the LOA
- Which resources it covers
- Who received it
- The authorized ASN
- Its purpose
- Its issue and expiry dates
- Whether it has been renewed or revoked
Best practices for providers receiving an LOA
Cloud, hosting, transit, and data-centre providers should:
- Receive the LOA through an authenticated channel
- Verify the authorizing organization
- Confirm the signatory’s authority
- Check the precise prefix
- Confirm the intended origin ASN
- Review RPKI status
- Review relevant IRR objects
- Check current routing
- Document the verification decision
- Define renewal and revocation procedures
- Monitor the prefix after activation
Automation can improve consistency. Conflicting or unusual information should still receive appropriate manual review.
LOAs and network identity
An IPv4 prefix can become part of an organization’s public network identity.
Customers, security platforms, partners, firewalls, payment systems, reputation databases, and compliance processes may associate trust with particular IP addresses and routing patterns.
Changes involving the origin ASN, provider, LOA, ROA, reverse DNS, geolocation, or registry information may therefore affect how a network is recognized.
An analysis of network identity for cloud, hosting, and telecom providers explains how IP addresses, ASNs, routing information, reputation, and operational history work together.
BTW.Media also covers developments in [Internet infrastructure and governance](https://btw.media/), connecting technical operations with wider policy and institutional questions.
Why LOA education matters
A Letter of Authorization sits at the intersection of technology, business, security, and Internet governance.
Understanding an LOA requires familiarity with:
- IP address administration
- BGP routing
- Autonomous Systems
- RPKI
- IRR databases
- Provider relationships
- Organizational authority
- Operational continuity
These topics should not be limited to network specialists. They are also relevant to students, legal professionals, policymakers, security teams, and organizations that depend on digital infrastructure.
LARUS Foundation works to make Internet infrastructure and governance easier to understand. Its [Universal Internet Education mission](https://larus.foundation/mission) supports broader public knowledge and participation.
Readers can also explore the Foundation’s educational programmes and partnerships, Internet governance Fellowship Programme, and other articles in the LARUS Foundation blog.
Conclusion
A Letter of Authorization connects control of an IPv4 resource with permission for another network to deploy or announce it.
A clear LOA identifies:
- The authorizing organization
- The authorized organization
- The IPv4 prefixes
- The permitted origin ASN
- The scope of authorization
- The effective period
- The responsible signatory
- The verification and revocation process
An LOA should not operate alone.
Reliable IPv4 deployment depends on several aligned layers:
- Commercial authorization
- Accurate registry information
- Correct IRR records
- Valid RPKI authorization
- Secure BGP configuration
- Routing monitoring
- Clear termination procedures
When these elements agree, IPv4 deployment becomes easier to verify, safer to operate, and more predictable for every participating network.
Frequently asked questions
1. What is an LOA for an IP address?
An LOA is a document through which an IP resource holder or authorized controller gives another organization permission to perform a specified action. In IPv4 deployment, this commonly means authorizing an ASN to announce a prefix.
2. Who issues an IPv4 LOA?
The IPv4 resource holder or another organization with documented authority over the resource should issue the LOA.
3. Who signs a Letter of Authorization?
An authorized representative of the issuing organization should sign or approve it. The signatory should have sufficient corporate or contractual authority.
4. Is an LOA required to announce an IPv4 prefix?
BGP does not technically require a paper LOA. However, transit providers, hosting companies, data centres, and cloud platforms may require one before accepting a customer’s prefix.
5. Is an LOA the same as a Route Origin Authorization?
No. An LOA is a commercial or operational document. A Route Origin Authorization is a cryptographically signed RPKI object that authorizes an ASN to originate specified prefixes.
6. Does an LOA prove ownership of an IPv4 block?
Not by itself. Providers may also examine registry data, contracts, RPKI, IRR objects, routing history, and direct confirmation from the resource controller.
7.Can an LOA authorize multiple ASNs?
It can, but the intended routing arrangement must be clear. Separate RPKI ROAs may be required because each ROA identifies one authorized origin ASN.
8. Should an IPv4 LOA have an expiry date?
An expiry date or clear revocation condition is recommended, especially for leases, migrations, and temporary deployments.
9. What happens when an LOA expires?
The parties should determine whether the authorization will be renewed. If not, routing, IRR, RPKI, reverse-DNS, and provider records should be updated as appropriate.
10. Can an LOA be issued electronically?
Yes. Providers may accept signed PDFs, electronic-signature workflows, authenticated portal approvals, or other digital formats. Requirements vary by provider.