Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Last Call - RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.

Ben Maddison benm at
Sat Jul 24 11:40:22 UTC 2021

Hi Jaco,

On 07/23, Jaco Kroon wrote:

> Hi Owen,


> Using as example, please clarify how the effect would be

> any different if this object would suddenly disappear off of the whois

> database?


> route:

> descr:          ROUTE-ULS1

> origin:         AS327767

> mnt-by:         ULTIMATELINUX-MNT

> source:         AFRINIC # Filtered


I realise that you directed your question to Owen, but I'll take the
liberty to respond instead.

There are fundamental differences between the semantics of route(6)
objects vs. the semantics of ROAs, and between the RPKI system and IRR

Consequently, there are substantial differences in practical impact.
Some of these are as follows:

1. The IRR system is a set of independent databases, with independent
object namespaces. Which databases are usable in practise is
determined only by the set of operators that mirror/query them when
generating filters.

It does not matter, in general, whether a route object for is published in the AFRINIC IRR or in another,
non-RIR managed database such as RADB, NTTCOM, ALTDB, etc.

The RPKI on the other hand is strictly (at least by design)
hierarchical. A ROA covering can *only* be validly
signed by the AFRINIC CA.

Thus, an operator loosing access to, and having their objects
deleted from, an RIR-managed IRR database has alternative
publication options. The same is not true in the case of ROA

2. Network operators typically re-build filters from IRR on a
relatively long, fixed schedule. Typically this is 24 hours,
although variation exists.

Conversely, ROAs wind up in the policy information bases of routers
as soon as permitted by the timers configured in the publication
pipeline and RP software involved. From my experience, this seems to
translate into a propagation delay of 10-60 mins in most cases.

As a result, the operator has around 2 orders of magnitude less time
to respond to the publication of an adverse ROA than they would to
the deletion of a route(6) object, before the problem deteriorates
into an outage.

3. A route(6) object in the IRR *only* makes a positive assertion. The
example you provided says that a route for and origin
AS327767 may exist. It doesn't say anything at all about any route
with either a different prefix, length or origin.

A ROA, however, makes both positive *and* negative assertions.
{ prefix:, asID: 327767 }
Says that a route for a prefix covered by that has
either: a) a length > 22; or b) an origin other than AS327767, is

A consequence of this distinction is that IRR-based prefix filters
are only useful when applied to sessions with customers or
moderately sized peers. Operators don't filter their transits in
this way, and transit-free networks don't filter one-another in this

An ROV Invalid, on the other hand, should not show up in the DFZ at
all, and filters to discard them are (correctly) applied on *all*
eBGP sessions at the AS border.

In practise, in the current example, the combination of the above 3
differences mean that:

Scenario A:
The example route object is deleted, and ULTIMATELINUX-MNT is
prevented from accessing the AFRINIC IRR database.

The operator will need to create replacement objects in some other
IRR database, such that these are visible to at least one of AS2914,
AS3356, AS5511, AS174 or AS6939. This probably involves nothing more
than creating an new maintainer on one of the non-RIR operated IRR

In the extreme and unlikely case where this is not achievable, the
operator would need to convince at least one of their transits to
configure a manual exception, and to request the same from one of
their transits in turn. This would represent intervention by at
minimum two operators. In all cases, the request would originate
from a paying customer.

The operator will have on average 12 hours to complete this before
an outage occurs.

Scenario B:
Same as scenario A + any existing ROAs for are
deleted, and replaced with one having asID: 0.

The operator will have to perform that mitigations in scenario A.

Additionally, the operator will have to make contact with *every
network operator in the world* that is relying on the TA under which
the new ROA is issued, providing them with sufficient information
and accompanying documentation to convince them:
- You are who you say you are;
- There is a bonafide dispute that warrants taking action to
override the stated intention of the RIR; and
- The impact to *their* network is sufficient to warrant taking the
trouble to deal with.

The operator will have approximately 10 - 60 mins to complete this
before an outage occurs.

Whether or not you believe placing operators in this position is
desirable, please can we at least stop pretending that scenario A & B
are even vaguely similar to one-another?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <>

More information about the RPD mailing list