-_-

Thanks for your patience. We have investigated more closely, and it appears that RIPE is going to roll out the change on the 4th of September. At that point new foreign objects can no longer be created and all existing foreign objects will change from "source: RIPE" to "source: RIPE-NONAUTH" meaning that a "bgpq3 -S RIPE" will only show the former but not the latter set of objects.

You can read more at the following links:

https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objects-in-the-ripe-database 

https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation 

Now, this change in procedures by RIPE is part of a larger push in the ecosystem for secure routing driven by companies like NTT Communications, which operates the NTTCOM IRRDB, as well as Merit Network, which operates the RADB IRRDB.

Given that the vast majority of prefix-filter generators are using the data which RADB mirrored from other registries and that NTT is one of our most important transit partners worldwide I thought it would be wise to get their thoughts on the way forward, so that we don't ask customers to change their procedures only to find out it has been for nothing because the next step in securing the routing ecosystem invalidates that method.

1) Firstly, all the RIRs which currently permit foreign objects in IRR are being pushed to clean up their databases: RIPE, as mentioned, will do this in September. ARIN's IRR is supposed to follow soon after.

2) IRRd, the software used to run an IRR instance, is being rewritten from C with a plaintext backend to Python with a PostgreSQL backend to allow for easier innovation. It is my understanding that the RADB and NTTCOM registries, as developing parties, have committed to rolling out IRRd v4 on their registries as a drop-in replacement of IRRd v3.

3) Once IRRd v4 has feature parity with IRRd v3, it will be deployed, at which point Phase 2 of the project will start to improve on the existing feature set. Again, both NTT and Merit are expected to take full advantage of the Phase 2 features.

4) One of the first features which will be seen is "RPKI accepted as route object", which will morph into "RPKI data drowns out conflicting route object data": https://github.com/irrdnet/irrd4/issues/3

5) Some registries like RADB, ALTDB, or a carrier operated registry such as NTTCOM or REACH permit anyone to register a route object rather than basing that permission on RIR/NIR registration data. As such, there will be a new read-only source named SECURE which is an alias for all sources considered to be secure by that IRRd instance operator: https://github.com/irrdnet/irrd4/issues/73 

6) Major transit operators and content networks have also started to work toward ignoring prefixes with an origin AS considered to be invalid by RPKI.

Therefore, my recommendations are as follows:

1) I strongly recommend creating RPKI ROAs for all of your announcements. Exact prefix length matches are required, so if you want a "le 24" style announcement you should not only create a ROA for say a /21, but also for the underlying /22, /23, /24 prefixes within that /21.

2) Eventually, many operators - including i3D.net - will move toward using the -S SECURE alias described in step 5 of my earlier list. Therefore, I would recommend also registering your prefixes in the IRR database of the RIR that assigned the address space to you, e.g. ARIN prefixes in ARIN's IRR/WHOIS system, and APNIC prefixes in APNIC's IRR system. Those route objects will complement RPKI for the time being since not all networks accept RPKI-as-route-object data yet.

Until the -S SECURE alias has been implemented i3D.net will generate its prefix-filters with the following command:

bgpq3 -h rr.ntt.net -A -l AS57695-PREFIXES -S RPKI,AFRINIC,APNIC,ARIN,ARIN-WHOIS,JPIRR,REGISTROBR,RIPE AS-MISAKA

Eventually, this will become:

bgpq3 -h rr.ntt.net -A -l AS57695-PREFIXES -S SECURE AS-MISAKA

Since RADB is not a RIR operated registry, it can't become part of the -S SECURE alias and that is why we won't be able to accept it as a source of routing information to build our prefix-filters.

I hope this helps to explain our decision on the way forward now that RIPE's DB-WG has decided to change its policies with regard to foreign route objects,

Best regards,

Martijn

Contact: Telephone & Ticket at i3D.net

Helpdesk open Mon - Fri 08:00 - 24:00

Helpdesk open Sat - Sun 10:00 - 18:00