SKNK Technical Guide
How to Arrange Route, ROA, and LOA for an IPv4 Lease
A practical way to put IRR route objects, ROAs, LOAs, and AS-SET work into one IPv4 leasing Order, with each item tied to the resource, Origin ASN, authority, and operating scope.
Technical content
Written and maintained by Shikanoko NetworksRoute, ROA, and LOA work for a leased IPv4 block all depend on the same facts: the exact prefix, Origin ASN, resource holder, registry maintainer, and operating model. They can share one Order and delivery timeline while each item remains tied to its actual authority and scope.
Separate the four objects
| Object | What it records | Common use |
|---|---|---|
| IRR route object | An IPv4 prefix and its Origin ASN as a routing-policy object | Operator filters and registry-data review |
| ROA | Which ASN may announce a prefix and the maximum length | RPKI origin validation |
| LOA | The party authorised to originate or use a prefix, its purpose, and its term | Authorisation and upstream coordination |
| AS-SET | A collection relationship for ASNs or route objects | Filter organisation based on the actual operational need |
The data model and verification path differ for each item. Registry data, cryptographic authorisation, contract authorisation, and live BGP state should be checked separately; the Order connects them to one delivery plan.
A practical confirmation sequence
1. Record the resource and Origin ASN
Start with the prefix, lease term, intended use, Origin ASN, and announcement model. When the Origin ASN is still under review, mark it as pending so that an incorrect authorisation is not created early.
2. Confirm the maintainer and authority source
An IRR route object needs usable maintainer authority. A ROA needs RPKI authority for the resource. An LOA needs the authorising party, authorised party, purpose, and validity term. Each record should name its maintenance owner in the delivery materials.
3. Define the change path
If the Origin ASN, prefix length, upstream, or announcement model changes, use a written change request to update the related records. The ROA maximum length should match the announcement plan.
4. Use lookup results for acceptance
Use the IRR route-object lookup to review registry objects. Use the RPKI and BGP lookup to compare ROA, Origin ASN, and observed BGP state.
Minimum Order fields
- IPv4 prefix and active term.
- Origin ASN, upstream, or designated routing provider.
- Scope for route object, ROA, LOA, and AS-SET.
- Maintainer, RPKI authority, and authorisation contact.
- Response path for creation, update, withdrawal, and Origin changes.
- Delivery record, evidence source, and review timestamp.
Advanced topologies, additional Origin ASNs, high-volume manual work, and customer-side network engineering are assessed and quoted per case. AS-SET follows the basic routing-registry requirement and available maintainer authority.
Common delivery mistakes
- Treating an IRR route object as proof of a live BGP announcement. They describe registry data and observed network state.
- Treating a Valid ROA as proof of end-to-end reachability. Origin authorisation and path propagation require separate checks.
- Issuing an LOA without the term, purpose, or Origin ASN. A later change then lacks an auditable authorisation context.
- Listing AS-SET as an extension service. It belongs with the actual filtering requirement and maintainer authority.
In one sentence
The route object records routing intent, the ROA records origin authorisation, the LOA records contractual authorisation, and AS-SET organises a basic routing set; tie all four to the resource and operating model in one Order.