RPKI, IRR, and ROA MaxLength: Routing Hygiene for Enterprises That Own Prefixes
Tech GuruIf your organization owns and announces public prefixes, routing hygiene needs both cryptographic intent and registry hygiene. Create accurate ROAs, keep IRR route objects aligned with real announcements, avoid overly broad ROA maxLength, and test how providers validate your routes before a turn-up or ASN change.
Operating principle: Publish only the origins and prefix lengths you intend to announce, stage registry changes before BGP changes, and keep a second credentialed operator available for recovery.
The Short Version
- RPKI origin validation says whether an origin AS is authorized; it does not validate the whole AS path.
- IRR objects still feed many provider filters, so stale route objects can break or over-permit announcements.
- Avoid broad
maxLengthunless you truly announce those more-specific prefixes.
The Reader Question
What should my company check if it announces public IP space?
This is for enterprise network owners with provider-independent address space, an autonomous system number (ASN), or authority over BGP announcements. It assumes access to the relevant Regional Internet Registry (RIR), Internet Routing Registry (IRR), provider portal, and external route views. The result should be an owner-approved prefix matrix and a turn-up process another credentialed operator can recover.
Before You Start: Safe Defaults
- Inventory exact IPv4/IPv6 prefixes, origin ASNs, provider/customer relationships, DDoS scrubbing origins, and planned more-specifics.
- Export current ROAs, IRR objects, provider filter records, and credential ownership before making changes.
- Create minimal ROAs for real or explicitly staged announcements, not broad future possibilities.
- Keep IRR
route/route6objects and AS-SETs aligned with actual policy and provider filter sources. - Stage registry changes before BGP changes, allow for cache/propagation time, and check multiple external route collectors.
- Require phishing-resistant multifactor authentication where available and at least two named RIR/IRR administrators.
Reference Model
The model below moves from ownership evidence to intended announcements, ROAs, IRR/provider filters, external observation, and recurring audit. Open each step and record an owner, timestamp, source system, and rollback action for each prefix.
Decision Matrix
| Choice | Best Fit | Watch Point |
|---|---|---|
| Exact ROA | Normal stable announcements | Needs updates when origin or prefix length changes. |
| ROA with maxLength | Specific planned more-specific announcements | Can authorize unused more-specifics if too broad. |
| IRR route object | Provider filter construction | Stale entries can permit or block wrong routes. |
| No routing hygiene | Legacy environments | Higher risk of outages, leaks, and failed turn-ups. |
ROA, IRR, and BGP Are Different Layers
A BGP announcement is what routers exchange. A Route Origin Authorization (ROA) is a signed RPKI object authorizing an origin ASN for one or more prefixes. A validated ROA produces Validated ROA Payloads used for Route Origin Validation (ROV). An IRR route or route6 object is registry data many networks still use to build customer prefix filters. They should agree, but they have different trust and enforcement paths.
Operational systems commonly label announcements Valid, Invalid, or NotFound based on origin and prefix-length authorization. Valid means the announcement matches at least one applicable payload; it does not mean the route is safe, preferred, reachable, or carried over an authorized AS path. IRR acceptance also does not make a cryptographically invalid origin valid.
The MaxLength Trap
A /22 ROA with maxLength /24 authorizes the named ASN to originate any covered /23 or /24, not only the one more-specific you had in mind. RFC 9319 recommends minimal ROAs and generally avoiding maxLength except where the operational need justifies the additional authorized space. Prefer exact entries for the aggregate and each intended more-specific. Document exceptions for pre-staged DDoS scrubbing or other emergency origins and remove them when the contract or plan ends.
ASPA Adds Path Context, but Start in Shadow Mode
ROV validates the origin, not the AS path. Autonomous System Provider Authorization (ASPA) objects let a customer AS declare authorized provider ASNs so validators can assess parts of provider-customer paths. By mid-2026, RIR support and RTR version 2 delivery are arriving, but the verification procedure is still standards-track work and global object coverage is sparse. Unknown is therefore common and is not the same as invalid.
For an enterprise prefix owner, the safe first step is publication review and observation: confirm every current transit provider, account for special relationships, receive validator data through a tested RPKI-to-Router (RTR) v2 path where supported, and correlate validation with pre-policy BGP Monitoring Protocol (BMP) data or equivalent. Alert and investigate before rejecting. Enforce only after vendor support, algorithm version, coverage, exceptions, fail-open/fail-closed behavior, and rollback have been tested.
Provider Turn-Up Checklist
Before changing transit providers, ASN, prefix length, DDoS service, or origin site, ask the provider which IRRs and AS-SETs build its filters, when those filters refresh, whether it rejects RPKI Invalids, and what evidence it needs for an emergency override. Create exact ROAs and IRR objects first, wait until independent validators and provider previews agree, then announce one approved prefix under a monitored window.
- Record the old and new origin ASN, prefix length, provider circuit, IRR source, RIR account, ROA state, and expected AS path.
- Verify route visibility and RPKI state from multiple collectors or validators; one looking glass is not global proof.
- Define a no-go condition for unexpected Invalid, missing provider filter, wrong origin, route leak, or loss of reachability.
- Keep the old circuit/origin ready until the new path is stable and the business owner approves withdrawal.
A Practical Pilot Scenario
Start with an offline audit, not a live routing change. Export every allocated prefix, observed announcement, origin ASN, ROA/VRP, IRR object, provider, and DDoS exception into one matrix. Choose one noncritical exact announcement for a controlled correction only after the matrix identifies the current provider filter and recovery path.
The audit passes when every observed route maps to approved intent, every intended route is Valid rather than accidentally Invalid, broad maxLength and stale IRR objects have named dispositions, provider contacts are current, and a second operator can access the accounts. ASPA passes the first phase when provider objects are reviewed and shadow telemetry is interpretable without dropping routes.
Implementation Details
Registry data can change reachability even though no router configuration changes. Treat each ROA, IRR, AS-SET, and ASPA update as a production change with before/after exports, peer review, propagation time, independent observation, and a reversal plan.
- Export allocations, public prefixes, origin ASNs, providers, DDoS origins, ROAs, IRR objects/AS-SETs, and observed BGP routes.
- Classify every mismatch: unauthorized observation, missing/stale intent, wrong origin, excessive
maxLength, or provider-filter dependency. - Confirm account ownership, multifactor authentication, backup administrators, billing/membership state, and emergency contacts.
- Ask each provider how it builds filters, refreshes IRR data, applies ROV, handles planned more-specifics, and supports rollback.
- Create exact ROAs for real/staged announcements; peer-review any
maxLengthor alternate-origin exception. - Create or correct authoritative IRR objects and remove stale entries only after provider dependencies are known.
- Validate from multiple independent views, then make the BGP change during a monitored window.
- Publish/review ASPA provider data where available, observe via RTRv2/BMP or an equivalent shadow workflow, and defer rejection until support and coverage are proven.
Evidence and Testing Method
- Status: documentation-backed. TechGeeks reviewed current IETF best practices, RIPE RPKI guidance, MANRS operations guidance, APNIC's July 2026 ASPA update, and an independent RIPE Labs shadow-visibility report. No live ROA, IRR, ASPA, or BGP change was performed for this draft.
- Save signed or timestamped exports from the RIR and IRR, provider filter previews, validator output, route-collector views, and the prefix-intent matrix.
- Observe from at least two networks or collectors before and after a change; record UTC timestamps, origin, prefix length, AS path, and RPKI state.
- For ASPA, record validator/RTR version, draft/algorithm support, object coverage, Unknown/Valid/Invalid counts, peer context, and exception decisions without enforcing.
- A route collector proves what its peers observed, not worldwide propagation or end-to-end reachability; add service probes from relevant regions.
Security, Legal, and Recovery Boundaries
RIR and IRR accounts can authorize changes affecting public reachability. Use individual accounts, strong multifactor authentication, least privilege, approval logs, and tested recovery contacts; do not share a single mailbox or leave authority with a former employee/provider. Only create objects for resources and relationships the organization is contractually authorized to manage. Follow RIR terms, provider contracts, incident-notification duties, and change-control requirements.
If an intended route becomes Invalid or disappears after a registry change, first confirm the announcement and validator state from independent views. Reverse the new ROA/IRR/ASPA object using the saved previous values, contact the provider with the change ID and timestamps, and keep the prior origin/path active where the migration design permits. RPKI cache propagation is not instantaneous, so do not oscillate objects repeatedly. For ASPA shadow deployment, disable the enforcement policy while preserving telemetry for analysis.
Validation Checklist
- Every announced prefix has an intended origin AS documented.
- RPKI state is Valid for intended announcements and not accidentally Invalid.
- IRR records match real provider filter needs.
- No broad maxLength exists without a written reason.
- External route collectors show the expected origin and reachability after changes.
Maintenance Cadence
- Daily or continuous: alert on new Invalids, origin changes, unexpected more-specifics, collector visibility loss, and validator/RTR failures.
- Monthly: reconcile observed BGP against ROAs, IRR/AS-SETs, provider filters, DDoS exceptions, and the approved prefix matrix.
- Quarterly: audit
maxLength, alternate origins, account access, MFA/recovery, provider contacts, and ASPA shadow results. - Before every provider, ASN, prefix-length, DDoS, merger, or address-transfer change: repeat the full audit and publication-day source check.
Troubleshooting
| Symptom | Likely Cause | First Check |
|---|---|---|
| Prefix becomes Invalid | ROA origin or maxLength does not match announcement | Compare route collector output to ROA prefix, origin AS, and maxLength. |
| Provider rejects route | IRR filter missing or stale | Check provider filter source and route/route6 object. |
| More-specific leak appears valid | maxLength too broad | Replace broad ROA with exact ROAs for intended announcements. |
Common Mistakes
- Creating one broad ROA and forgetting it for years.
- Leaving old IRR objects for providers you no longer use.
- Assuming RPKI validates the entire BGP path.
- Changing upstream providers before route objects and ROAs are ready.
- Letting registry credentials live with one unavailable person.
Related TechGeeks Reading
What This Evidence Does Not Prove
A Valid RPKI origin proves that one ROA authorizes the observed origin and prefix length. It does not prove that the origin is uncompromised, the full AS path is legitimate, the route is reachable, the IRR object is current, or every network enforces ROV. An IRR match proves only that the selected registry data permits a filter entry under the provider's process.
ASPA shadow results do not prove global path protection: coverage is sparse, Unknown is common, implementations follow evolving standards work, and enforcement behavior varies. External collectors sample their peers rather than the whole internet. Use them with provider confirmation, validator health, service probes, and local BGP evidence.
Practical FAQ
Do I need RPKI if I only have one provider?
Yes, if you own public address space. Single-homed does not remove the need to state which AS may originate it.
Should maxLength always be avoided?
Avoid broad maxLength by default. Use it only when there is a specific operational reason and review it regularly.
Does IRR still matter?
Yes. Many providers still use IRR-derived filters even when they also use RPKI origin validation.
References
- RFC 9582: current RPKI ROA profile
- RFC 6811: BGP prefix origin validation
- RFC 9319 / BCP 185: prudent use of ROA maxLength
- RIPE NCC: ROA management and max-length guidance
- MANRS implementation guide for network operators
- APNIC: ASPA launch and path-validation context, July 2026
- RIPE Labs: independent ASPA/RTRv2/BMP shadow-visibility analysis
Final Thought
Routing hygiene is boring until it is missing. Exact ROAs, clean IRR objects, and provider-ready filters turn prefix ownership into an operating process instead of tribal knowledge.
