Quickstart Guide to IRR/RPSL

Job Snijders job at ntt.net
Thu Jul 19 16:19:33 UTC 2018

Dear Kenneth,

On Wed, Jul 18, 2018 at 09:38:23PM -0700, Kenneth Finnegan wrote:
> As part of setting up a new Internet Exchange in Fremont, California,
> we've been investigating prefix filtering on the route servers based
> on IRR.

Excellent, have you also considered using ARIN-WHOIS and RPKI as data
sources for your route servers? An excellent tool to generate route
server configurations is 'arouteserver' http://arouteserver.readthedocs.io/

> Unfortunately, we were not satisfied with any of the existing
> documentation available online as far as taking a network engineer
> from "zero" to "just enough IRR to post our prefixes for filtering".
> Lacking this documentation, it was rather unreasonable for us to turn
> on filtering and drop most of our peer's prefixes without a relevant
> whitepaper to point them to to get started.
> So, we wrote our own guide:
> http://fcix.net/whitepaper/2018/07/14/intro-to-irr-rpsl.html

This is excellent reasoning, there indeed is a lack of easy to consume

> I thought others on this list would find our whitepaper interesting,
> and/or have valuable feedback based on their experience applying IRR
> themselves.

1/ About the "Selecting an IRR Database" section, the best current
practise is to use the IRR that your RIR provides you. In other words:
register ARIN managed prefixes in the ARIN IRR, and RIPE managed
prefixes in the RIPE IRR. Only the RIRs are in a position to attest that
it was the owner of a prefix that created the route(6): object.

Databases such as RADB, NTTCOM, ALTDB are so-called "third party"
databases and at this moment in time have no way to validate anything.
I've highlighted the differences between the various sources of data in
this talk at RIPE76 https://ripe76.ripe.net/archives/video/22

Also, in most regions people are paying their RIR money, this money pays
for IRR services so I'd recommend to use those.

2/ I'd delete the "Step 2: Document Your Autonomous System’s Routing
Policy" step, nobody uses this.

3/ Step 3 is excellent, everybody who generates filters uses AS-SETs. I
like how detail was given to the "AS15562:AS-SNIJDERS" format to ensure
unique names. Good work.

4/ Step 4 can be extended to promote creating RPKI ROAs (in addition to)
the route objects. Anyone can create a route: object in ALTDB, but only
the owner of a prefix can create a RPKI ROA. As such the RPKI ROAs are a
far more valuable source of data to filter generators.

In summary, great work!

Can I update http://peering.exposed/ and add FCIX with a 'yes' to both
secure route servers & BCP 214? :-)

Kind regards,


More information about the NANOG mailing list