{"id":24842,"date":"2026-10-04T13:29:17","date_gmt":"2026-10-04T13:29:17","guid":{"rendered":"https:\/\/atalnetworks.com\/?p=24842"},"modified":"2026-10-04T13:29:38","modified_gmt":"2026-10-04T13:29:38","slug":"loa-vs-irr-route-objects-vs-roa","status":"publish","type":"post","link":"https:\/\/atalnetworks.com\/el\/loa-vs-irr-route-objects-vs-roa\/","title":{"rendered":"LOA vs IRR Route Objects vs ROA: Differences and Requirements"},"content":{"rendered":"<\/h1>\n
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.<\/span><\/p>\nAn 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.<\/b><\/p>\n
At Atal Networks, we recommend checking these records against the intended network arrangement before deploying leased addresses or moving existing IP space.<\/span><\/p>\nLOA vs IRR Route Objects vs ROA at a Glance<\/b><\/h2>\n
These records support different parts of the deployment process. They are related, but they are not interchangeable.<\/span><\/p>\n\n\n\n| Comparison<\/b><\/td>\n | \u03bb\u03c9\u03c4\u03cc\u03c2<\/b><\/td>\n | IRR route object<\/b><\/td>\n | ROA<\/b><\/td>\n<\/tr>\n\n| Full name<\/span><\/td>\n | Letter of Authorization, sometimes Letter of Agency<\/span><\/td>\n | Internet Routing Registry route object<\/span><\/td>\n | Route Origin Authorization<\/span><\/td>\n<\/tr>\n\n| Main purpose<\/span><\/td>\n | Documents permission for an agreed announcement arrangement<\/span><\/td>\n | Records a prefix-origin relationship<\/span><\/td>\n | Authorizes an origin ASN and permitted prefix lengths<\/span><\/td>\n<\/tr>\n\n| Format<\/span><\/td>\n | Provider-accepted document or authorization workflow<\/span><\/td>\n | Structured routing registry record<\/span><\/td>\n | Cryptographically signed RPKI object<\/span><\/td>\n<\/tr>\n\n| Main user<\/span><\/td>\n | Provider reviewing the request<\/span><\/td>\n | Operators building routing policies and filters<\/span><\/td>\n | Systems performing route-origin checks<\/span><\/td>\n<\/tr>\n\n| Who controls it?<\/span><\/td>\n | Authorized resource representative<\/span><\/td>\n | Authorized registry maintainer<\/span><\/td>\n | Authorized resource administrator through RPKI<\/span><\/td>\n<\/tr>\n\n| Starts a BGP announcement?<\/span><\/td>\n | \u038c\u03c7\u03b9<\/span><\/td>\n | \u038c\u03c7\u03b9<\/span><\/td>\n | \u038c\u03c7\u03b9<\/span><\/td>\n<\/tr>\n\n| Guarantees reachability?<\/span><\/td>\n | \u038c\u03c7\u03b9<\/span><\/td>\n | \u038c\u03c7\u03b9<\/span><\/td>\n | \u038c\u03c7\u03b9<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n An upstream provider may require several checks before accepting your prefix. Meeting one requirement does not automatically satisfy the others.<\/span><\/p>\nWe also separate these records from <\/span>observed BGP state<\/b>, which shows what networks are actually announcing.<\/span><\/p>\nAn LOA Documents Permission to Announce IP Space<\/b><\/h2>\nA Letter of Authorization records permission for a specified network to announce or use address space under an agreed arrangement.<\/span><\/p>\nProviders use it during onboarding, IP leasing, BYOIP deployment, and some routing changes. Cloudflare uses the term Letter of Agency for its BYOIP authorization document.<\/span><\/p>\nInformation an LOA Usually Contains<\/b><\/h3>\nThe receiving provider may request:<\/span><\/p>\n\n- IP prefixes in CIDR notation.<\/span><\/li>\n
- The resource holder\u2019s organization name.<\/span><\/li>\n
- The authorized provider or network.<\/span><\/li>\n
- Relevant ASN details.<\/span><\/li>\n
- The purpose and scope of the permission.<\/span><\/li>\n
- An authorized signature and date.<\/span><\/li>\n
- Contact information and any required validity period.<\/span><\/li>\n<\/ul>\n
Use the provider\u2019s requested format. The network receiving permission and the origin ASN visible in BGP are not necessarily identical in every service arrangement.<\/span><\/p>\nFor leased IP addresses, the provider may need authorization from the registered resource holder or evidence of delegated authority. A customer\u2019s signature alone may not satisfy the requirement.<\/span><\/p>\nAn LOA Does Not Grant Database Access<\/b><\/h3>\nAn accepted LOA does not permit you to edit another organization\u2019s registry records. It also does not create route objects, publish ROAs, or configure a router.<\/span><\/p>\nThose actions require separate access and authority.<\/span><\/p>\nBefore 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.<\/span><\/p>\nIRR Route Objects Record Routing Information<\/b><\/h2>\nAn Internet Routing Registry stores information that network operators can use to describe routing policy and build filters.<\/span><\/p>\nIRR is an ecosystem of registries, not one database with identical controls everywhere. Providers choose which sources and records they use.<\/span><\/p>\nUnderstand route and route6 Objects<\/b><\/h3>\nA <\/span>route<\/span> object describes an IPv4 prefix and its origin ASN. A <\/span>route6<\/span> object serves the corresponding purpose for IPv6.<\/span><\/p>\nCommon fields include:<\/span><\/p>\n\n\n\n| Field<\/b><\/td>\n | Meaning<\/b><\/td>\n<\/tr>\n\n| route<\/span> \u03ae <\/span>route6<\/span><\/td>\n | The IP prefix<\/span><\/td>\n<\/tr>\n\n| origin<\/span><\/td>\n | The ASN recorded as originating the route<\/span><\/td>\n<\/tr>\n\n| mnt-by<\/span><\/td>\n | The maintainer controlling the object<\/span><\/td>\n<\/tr>\n\n| source<\/span><\/td>\n | The registry source<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n RIPE\u2019s 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.<\/span><\/p>\nCreating an Object Does Not Announce the Prefix<\/b><\/h3>\nA route object supplies registry information. Your routing device or provider still needs to announce the prefix through Border Gateway Protocol, or BGP.<\/span><\/p>\nAn accurate object can exist while no corresponding route appears on the Internet.<\/span><\/p>\nThe 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.<\/span><\/p>\nConfirm Which Registry Your Provider Uses<\/b><\/h3>\nCreating an object in one registry may not satisfy an upstream that builds filters from another source.<\/span><\/p>\nWe 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\u2019s route object.<\/span><\/p>\nA ROA Authorizes the Route Origin Through RPKI<\/b><\/h2>\nA Route Origin Authorization is a signed object within Resource Public Key Infrastructure, or RPKI.<\/span><\/p>\nIt 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.<\/span><\/p>\nPrefix, Origin ASN, and Maximum Length<\/b><\/h3>\nA ROA identifies the authorized ASN and one or more prefixes. An optional <\/span>maxLength<\/span> value controls which more-specific prefix lengths the authorization permits.<\/span><\/p>\nIf <\/span>maxLength<\/span> is absent, the authorization permits the listed prefix length only.<\/span><\/p>\nFor example, permission for an aggregate does not automatically authorize every smaller block inside it. The permitted length matters as well as the ASN.<\/span><\/p>\nWe 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 <\/span>maxLength<\/span> expansion.<\/span><\/p>\nValid, Invalid, and NotFound: Describe the Route<\/b><\/h3>\nA route-origin check produces one of three states:<\/span><\/p>\n\n- Valid:<\/b> At least one matching authorization permits the route\u2019s origin ASN and prefix length.<\/span><\/li>\n
- Invalid:<\/b> A covering authorization exists, but none permits that announcement.<\/span><\/li>\n
- NotFound:<\/b> No covering authorization exists.<\/span><\/li>\n<\/ul>\n
These states describe the BGP route\u2019s relationship to available RPKI authorization data. They do not describe application health.<\/span><\/p>\nA missing covering ROA does not automatically make a route Invalid.<\/b> It produces NotFound. Each network applies its own route-acceptance policy to the result.<\/span><\/p>\nA ROA Does Not Secure the Entire Route<\/b><\/h3>\nOrigin 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.<\/span><\/p>\nA route can pass its origin check and still fail another provider filter or lead to a server that does not respond.<\/span><\/p>\nCompare the Records Against One BGP Announcement<\/b><\/h2>\nConsider a hypothetical customer preparing this deployment:<\/span><\/p>\n\n\n\n| Item<\/b><\/td>\n | Intended value<\/b><\/td>\n<\/tr>\n\n| IP prefix<\/span><\/td>\n | 203.0.113.0\/24<\/span><\/td>\n<\/tr>\n\n| Origin ASN<\/span><\/td>\n | AS64496<\/span><\/td>\n<\/tr>\n\n| \u03bb\u03c9\u03c4\u03cc\u03c2<\/span><\/td>\n | Permits the agreed announcement arrangement<\/span><\/td>\n<\/tr>\n\n| IRR route object<\/span><\/td>\n | Records <\/span>203.0.113.0\/24<\/span> with origin <\/span>AS64496<\/span><\/td>\n<\/tr>\n\n| ROA<\/span><\/td>\n | Authorizes <\/span>AS64496<\/span> for that \/24<\/span><\/td>\n<\/tr>\n\n| Actual BGP announcement<\/span><\/td>\n | Originates the same \/24 from <\/span>AS64496<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n These addresses and ASN are for documentation only. Do not use them for production announcements.<\/span><\/p>\nThe records align in this example, but the final check still requires observed routing and service tests.<\/span><\/p>\nCommon Ways the Records Disagree<\/b><\/h3>\nAssume each example has no additional matching ROA.<\/span><\/p>\n\n\n\n| Situation<\/b><\/td>\n | Result or concern<\/b><\/td>\n<\/tr>\n\n| The LOA is accepted, but nobody announces the prefix<\/span><\/td>\n | The document does not create connectivity<\/span><\/td>\n<\/tr>\n\n| BGP shows another origin ASN<\/span><\/td>\n | The route fails the stated origin authorization<\/span><\/td>\n<\/tr>\n\n| The route object still names the previous ASN<\/span><\/td>\n | An IRR-based filter may reject the new announcement<\/span><\/td>\n<\/tr>\n\n| The announcement is more specific than the ROA permits<\/span><\/td>\n | The route can receive an Invalid result<\/span><\/td>\n<\/tr>\n\n| The route passes RPKI checks, but a required IRR object is missing<\/span><\/td>\n | A separate upstream filter may still reject it<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Check all relevant authorizations before diagnosing a mismatch. A route may match one permitted authorization even when another covering entry does not match.<\/span><\/p>\nFor prefix-length testing, also separate RPKI permission from Internet acceptance. A more-specific route can pass an origin check yet fail a provider\u2019s prefix-length policy.<\/span><\/p>\nDoes One Record Replace the Others?<\/b><\/h2>\nThere is no universal replacement rule. The receiving provider\u2019s requirements and filtering methods determine what the deployment needs.<\/span><\/p>\nAn LOA Does Not Replace an IRR Object or ROA<\/b><\/h3>\nManual approval does not update registry data or change cryptographic origin permissions.<\/span><\/p>\nA 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.<\/span><\/p>\nA ROA Does Not Universally Remove IRR Requirements<\/b><\/h3>\nSome operators use RPKI-derived data when building routing filters. Others still require particular IRR objects or AS-SET information.<\/span><\/p>\nAsk your upstream which inputs it uses. Avoid assuming that a Valid origin result satisfies every routing policy.<\/span><\/p>\nAutomation Can Link the Records<\/b><\/h3>\nSome registry services can create matching IRR objects from ROAs.<\/span><\/p>\nARIN\u2019s IRR Auto-Manager provides this function, but its documentation states that it uses the listed prefix rather than expanding <\/span>maxLength<\/span> into every possible more-specific route object. Additional intended announcements may need separate attention.<\/span><\/p>\nAutomation reduces duplicate work. It does not make the records identical or remove the need to check the final result.<\/span><\/p>\nAssign Ownership Before Making Changes<\/b><\/h2>\nThe party using the addresses may not control every related record.<\/span><\/p>\nFor 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.<\/span><\/p>\n\n\n\n| Task<\/b><\/td>\n | Party to identify<\/b><\/td>\n<\/tr>\n\n| Approve and sign the LOA<\/span><\/td>\n | Authorized resource representative<\/span><\/td>\n<\/tr>\n\n| Create or change IRR objects<\/span><\/td>\n | Authorized registry maintainer<\/span><\/td>\n<\/tr>\n\n| Create or change ROAs<\/span><\/td>\n | Authorized RPKI administrator<\/span><\/td>\n<\/tr>\n\n| Confirm the intended origin ASN<\/span><\/td>\n | Customer and announcing network<\/span><\/td>\n<\/tr>\n\n| Configure BGP announcements<\/span><\/td>\n | Agreed routing operator<\/span><\/td>\n<\/tr>\n | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |