A hosting provider can accept your Letter of Authorization while your IP prefix remains unreachable. The paperwork may be correct, but a routing record could point to the wrong ASN, an upstream filter could reject the announcement, or the network might not announce the prefix at all.

An LOA documents permission. An IRR route object records a prefix and its origin ASN. A ROA provides cryptographic authorization for an ASN to originate specified prefixes. None of these creates a working BGP route by itself.

At Atal Networks, we recommend checking these records against the intended network arrangement before deploying leased addresses or moving existing IP space.

LOA vs IRR Route Objects vs ROA at a Glance

These records support different parts of the deployment process. They are related, but they are not interchangeable.

Comparison	LOA	IRR route object	ROA
Full name	Letter of Authorization, sometimes Letter of Agency	Internet Routing Registry route object	Route Origin Authorization
Main purpose	Documents permission for an agreed announcement arrangement	Records a prefix-origin relationship	Authorizes an origin ASN and permitted prefix lengths
Format	Provider-accepted document or authorization workflow	Structured routing registry record	Cryptographically signed RPKI object
Main user	Provider reviewing the request	Operators building routing policies and filters	Systems performing route-origin checks
Who controls it?	Authorized resource representative	Authorized registry maintainer	Authorized resource administrator through RPKI
Starts a BGP announcement?	Non	Non	Non
Guarantees reachability?	Non	Non	Non

An upstream provider may require several checks before accepting your prefix. Meeting one requirement does not automatically satisfy the others.

We also separate these records from observed BGP state, which shows what networks are actually announcing.

An LOA Documents Permission to Announce IP Space

A Letter of Authorization records permission for a specified network to announce or use address space under an agreed arrangement.

Providers use it during onboarding, IP leasing, BYOIP deployment, and some routing changes. Cloudflare uses the term Letter of Agency for its BYOIP authorization document.

Information an LOA Usually Contains

The receiving provider may request:

• IP prefixes in CIDR notation.
• The resource holder’s organization name.
• The authorized provider or network.
• Relevant ASN details.
• The purpose and scope of the permission.
• An authorized signature and date.
• Contact information and any required validity period.

Use the provider’s requested format. The network receiving permission and the origin ASN visible in BGP are not necessarily identical in every service arrangement.

For leased IP addresses, the provider may need authorization from the registered resource holder or evidence of delegated authority. A customer’s signature alone may not satisfy the requirement.

An LOA Does Not Grant Database Access

An accepted LOA does not permit you to edit another organization’s registry records. It also does not create route objects, publish ROAs, or configure a router.

Those actions require separate access and authority.

Before scheduling deployment, identify the person who can make each change. This matters when the hosting customer, IP lessor, and registered holder are three different parties.

IRR Route Objects Record Routing Information

An Internet Routing Registry stores information that network operators can use to describe routing policy and build filters.

IRR is an ecosystem of registries, not one database with identical controls everywhere. Providers choose which sources and records they use.

Understand route and route6 Objects

A route object describes an IPv4 prefix and its origin ASN. A route6 object serves the corresponding purpose for IPv6.

Common fields include:

Field	Meaning
route ou alors route6	The IP prefix
origin	The ASN recorded as originating the route
mnt-by	The maintainer controlling the object
source	The registry source

RIPE’s documentation defines the prefix and origin as the combined primary key of a route object. It also describes separate authorization procedures for creating and maintaining objects.

Creating an Object Does Not Announce the Prefix

A route object supplies registry information. Your routing device or provider still needs to announce the prefix through Border Gateway Protocol, or BGP.

An accurate object can exist while no corresponding route appears on the Internet.

The reverse can also happen: a network announces a prefix while registry information remains missing or outdated. Whether another network accepts that announcement depends on its policies.

Confirm Which Registry Your Provider Uses

Creating an object in one registry may not satisfy an upstream that builds filters from another source.

We recommend confirming the accepted IRR sources, exact prefix-origin requirements, and filter-refresh process. If the provider requests an AS-SET, check its membership as well. An AS-SET groups ASNs or other AS-SETs; it does not replace the prefix’s route object.

A ROA Authorizes the Route Origin Through RPKI

A Route Origin Authorization is a signed object within Resource Public Key Infrastructure, or RPKI.

It allows a resource holder to authorize an ASN to originate specified address space. Networks can compare BGP announcements against trusted data derived from published ROAs.

Prefix, Origin ASN, and Maximum Length

A ROA identifies the authorized ASN and one or more prefixes. An optional maxLength value controls which more-specific prefix lengths the authorization permits.

If maxLength is absent, the authorization permits the listed prefix length only.

For example, permission for an aggregate does not automatically authorize every smaller block inside it. The permitted length matters as well as the ASN.

We recommend authorizing the prefixes you intend to announce rather than adding broad permissions for convenience. RFC 9319 recommends narrow ROAs and explains the risks of unnecessary maxLength expansion.

Valid, Invalid, and NotFound: Describe the Route

A route-origin check produces one of three states:

• Valid: At least one matching authorization permits the route’s origin ASN and prefix length.
• Invalid: A covering authorization exists, but none permits that announcement.
• NotFound: No covering authorization exists.

These states describe the BGP route’s relationship to available RPKI authorization data. They do not describe application health.

A missing covering ROA does not automatically make a route Invalid. It produces NotFound. Each network applies its own route-acceptance policy to the result.

A ROA Does Not Secure the Entire Route

Origin checks do not prove that every network in the AS path is legitimate. They also do not confirm firewall settings, server availability, or application safety.

A route can pass its origin check and still fail another provider filter or lead to a server that does not respond.

Compare the Records Against One BGP Announcement

Consider a hypothetical customer preparing this deployment:

Item	Intended value
IP prefix	203.0.113.0/24
Origin ASN	AS64496
LOA	Permits the agreed announcement arrangement
IRR route object	Records 203.0.113.0/24 with origin AS64496
ROA	Authorizes AS64496 for that /24
Actual BGP announcement	Originates the same /24 from AS64496

These addresses and ASN are for documentation only. Do not use them for production announcements.

The records align in this example, but the final check still requires observed routing and service tests.

Common Ways the Records Disagree

Assume each example has no additional matching ROA.

Situation	Result or concern
The LOA is accepted, but nobody announces the prefix	The document does not create connectivity
BGP shows another origin ASN	The route fails the stated origin authorization
The route object still names the previous ASN	An IRR-based filter may reject the new announcement
The announcement is more specific than the ROA permits	The route can receive an Invalid result
The route passes RPKI checks, but a required IRR object is missing	A separate upstream filter may still reject it

Check all relevant authorizations before diagnosing a mismatch. A route may match one permitted authorization even when another covering entry does not match.

For prefix-length testing, also separate RPKI permission from Internet acceptance. A more-specific route can pass an origin check yet fail a provider’s prefix-length policy.

Does One Record Replace the Others?

There is no universal replacement rule. The receiving provider’s requirements and filtering methods determine what the deployment needs.

An LOA Does Not Replace an IRR Object or ROA

Manual approval does not update registry data or change cryptographic origin permissions.

A provider can accept your signed letter while its automated filters continue rejecting the announcement. Correct the relevant record rather than assuming the document overrides the filter.

A ROA Does Not Universally Remove IRR Requirements

Some operators use RPKI-derived data when building routing filters. Others still require particular IRR objects or AS-SET information.

Ask your upstream which inputs it uses. Avoid assuming that a Valid origin result satisfies every routing policy.

Automation Can Link the Records

Some registry services can create matching IRR objects from ROAs.

ARIN’s IRR Auto-Manager provides this function, but its documentation states that it uses the listed prefix rather than expanding maxLength into every possible more-specific route object. Additional intended announcements may need separate attention.

Automation reduces duplicate work. It does not make the records identical or remove the need to check the final result.

Assign Ownership Before Making Changes

The party using the addresses may not control every related record.

For customer-held resources, one organization may manage the whole process. With leased space, the lessor or another authorized administrator may control registry and RPKI access.

Task	Party to identify
Approve and sign the LOA	Authorized resource representative
Create or change IRR objects	Authorized registry maintainer
Create or change ROAs	Authorized RPKI administrator
Confirm the intended origin ASN	Customer and announcing network
Configure BGP announcements	Agreed routing operator
Refresh upstream filters	Relevant provider
Test external reachability	Customer and provider within their support scope

For leased IPv4 addresses, include change-request contacts and response expectations in the operational handoff.

The provider cannot directly edit records controlled by another organization without suitable authority. Identify that dependency before an urgent migration or incident.

Update Records Safely During a Provider or ASN Change

A move to a new network may change the origin ASN, announcement permissions, registry records, or all three.

We recommend treating those updates as one controlled change.

Record the Existing State

Before editing anything, collect the current prefixes, origin ASNs, IRR sources, ROA permissions, provider filters, and observed announcements.

Keep a copy of the accepted LOA and note who approved it.

Prepare the New Arrangement

Confirm the receiving provider’s requirements. Obtain the necessary permission, publish the intended IRR and ROA changes, and check what the provider’s systems can see.

Registry publication, RPKI data refresh, and upstream filter updates follow different processes. Do not rely on one fixed waiting period for all of them.

A planned migration may temporarily authorize more than one origin ASN. That permission does not itself make concurrent announcements safe; the routing design still needs review.

Change Routing, Test, and Remove Old Permissions

After confirming readiness:

1. Apply the agreed routing change.
2. Check external prefix visibility and origin.
3. Test application access from multiple networks.
4. Keep the approved rollback path available.
5. Remove obsolete permissions after the rollback window closes.

Avoid removing the old authorization too early. Also avoid leaving it in place indefinitely without an operational reason.

Troubleshoot Routing Mismatches in the Right Order

Start with evidence from each part of the process.

Symptom	First checks
Provider rejects the LOA	Signer authority, prefix, scope, ASN details, and required format
IRR object exists but route is filtered	Accepted registry source, exact prefix-origin pair, AS-SET if required, and filter refresh
Route has an Invalid origin result	All covering authorizations, actual origin ASN, and permitted prefix length
Route is Valid but unreachable	Announcement status, other filters, forwarding path, server routing, and firewall
Records changed but behavior did not	Publication state, cached data, provider refresh, and active configuration
Previous provider still appears as origin	Existing announcements and the withdrawal plan

Collect the prefix, observed ASN, timestamp, lookup source, and relevant provider ticket. External route observations help, but one looking glass cannot prove reachability from every network.

Do not delete a ROA as the default response to an Invalid result. First establish whether the announcement or authorization is wrong, then correct the intended arrangement through the authorized party.

Prepare Routing Records for an Atal Networks Deployment

Before discussing an IP deployment with our team, prepare:

• Exact IPv4 and IPv6 prefixes.
• Intended origin ASN and announcing network.
• Resource holder and authorized contacts.
• Lease status, where applicable.
• Existing LOA, IRR, and ROA details.
• Current announcement information.
• Target server location and change window.

Atal Networks’ IPv4, IPv6, and ASN leasing services list LOA, route objects, and RPKI among their IP-service features. Confirm the scope for your resource and location, including who controls each record.

For dedicated-server deployments, coordinate record preparation with server readiness. Correct permissions cannot compensate for an incomplete delivery route or application setup.

Questions fréquemment posées

Do I need an LOA, an IRR route object, and a ROA?

Your provider determines its onboarding and filtering requirements. Many deployments use all three, but do not assume every network follows the same process.

Does a ROA replace an IRR route object?

Not universally. Some networks use RPKI-derived information, while others require selected IRR records. Confirm the policy with your upstream.

Can a route be RPKI Valid but still be rejected?

Yes. Prefix-length restrictions, IRR-based filters, customer routing policy, and other checks can still prevent acceptance.

Does a missing ROA make a route Invalid?

No. Without a covering authorization, the result is NotFound. Invalid means covering authorization exists, but none matches the announcement.

Who creates records for leased IP addresses?

The party with the necessary authority creates them. That may be the resource holder, lessor, or an authorized administrator rather than the server customer.

Can multiple ASNs have permission for the same prefix?

Yes. Multiple origin authorizations can support an intended arrangement. They do not configure routing or guarantee that concurrent announcements suit the application.

Does an LOA allow me to edit registry records?

Not by itself. Registry and RPKI changes require their own access controls and authorized roles.

Does creating a route object make my addresses reachable?

No. The routing operator must announce the prefix, the provider must deliver traffic correctly, and the destination service must respond.

Recommended Next Steps

Compare the intended prefix and origin ASN across your LOA, IRR records, ROAs, and actual BGP announcements. Assign an owner to every change and check provider acceptance before moving production traffic.

Discuss your IP prefixes, origin ASN, and routing-record requirements with Atal Networks.