Summary: RPSL changes at the RIPE NCC on 4 September will affect resource holders in the APNIC region.
There is a significant change occurring to the routing policy specification in routing registries, specifically the RIPE Internet Routing Registry (IRR) service. From 4 September, a lot of data reflecting routing for regions outside the RIPE region will be moving. APNIC address holders need to be aware of this change and how they can manage their routing policy in future using APNIC services.
Details of how to import routing objects into APNIC are available on the APNIC website.
Details of the changes coming from RIPE have been discussed on a range of operator mailing lists and on the RIPE NCC website, which says:
“the Routing Registry will no longer support the creation of out-of-region route(6) and aut-num objects. Also, creation of route(6) objects will no longer need authorization from the ASN holder. Existing out-of-region objects will have their “source:” attribute changed to “RIPE-NONAUTH” and may be subject to further discussions by the community.”
These changes will affect 2,939 route objects in the APNIC space.
What’s the problem?
As many of you will know, APNIC Secretariat staff have been helping Internet Number Resource (INR) holders with ongoing operational problems that stem from their resources being seen to be referenced by out-of-region IRR records. The main source of the problems stems from two major sources of IRR activity: the Merit RADB (which is fully independent of the RIR system and operates as a standalone source of routing information); and the RIPE Database, which is the principal European source of routing policy statements.
The RIPE Database (whois) operates both as a delegation registry for resources distributed under RIPE address policy, and as a source of ROUTING policy statements, which are not at all about address allocation and assignment, but about address usage in the BGP. The mechanisms here depend on information managed by the resource holders themselves — statements of policy intent regarding the routing of their addresses.
For the benefit of RIPE NCC Members, the RIPE Database has previously offered a ‘well-known maintainer’ system to permit resources from outside the RIPE NCC service region to be included by RIPE resource managers in their routing policy statements. The problem is that this mechanism carried with it the seeds of the problem: anyone with any resource rights in the RIPE Database could create and maintain data about resources from the rest of the world, with no constraint on their authority or ability to make these policy statements. Basically, this permitted bad actors to hijack prefixes from the APNIC, AFRINIC, LACNIC and ARIN regions and have anyone who did automatic prefix filtering from IRRs accept their origination. The problem got out of hand.
As a result, and after many years of discussion in the RIPE NCC service region’s routing-wg and db-wg lists, the RIPE NCC is in the process of enacting a pair of significant changes that we have previously discussed here — closing the loophole and cleaning up the data.
The two changes being applied
Firstly, the well known maintainer will be closed off. After this, no new changes can be propagated into the RIPE Database. This will take effect at the same time as the other change later this year (in September, at the time of writing). At this point, all current data in the system will be effectively ‘grandfathered in’ and continued as-is.
The second change is in the process of being finalized and will be deployed with the first change around 4 September. This is the relocation of the foreign objects (that is, objects in RPSL notation that refer to any INR that does not vest inside the RIPE NCC service region’s coordination) into a new IRR source. The current resources managed by the RIPE address policy process will reside in source: RIPE NCC and foreign sourced data will reside in source: RIPE-NONAUTH.
What do these changes mean for RPSL consumers, regarding resource holders from the APNIC region?
If you are currently managing your routing by using the RIPE Database to read IRR objects in RPSL, from around 4 September these objects will reside in a range of sources, and your IRR tools will need to be modified to fetch an additional source: RIPE-NONAUTH. This change is not hard to configure; most tools already consume multiple IRR inputs. You just need to add another one.
If you mirror the RIPE Database, you will probably want to modify your NRTM mirror configuration to receive RIPE-NONAUTH, which will require initial bootstrap.
What do these changes mean for RPSL maintainers who are resource holders from the APNIC region?
Because of the policy change in the RIPE region, you can no longer maintain your routing data in the RIPE Database. Your existing data is maintained, but future change will be limited. If you have an active need to modify this data, foresee future need, or want to add additional INRs to your routing policy statements, APNIC offers an IRR service locally that we invite you to use instead. This mechanism respects your authority to act, which is vested through your access to APNIC services.
It is possible you may need to reference data (ASNs, prefixes) that do not form part of the APNIC registry. This is discussed in our web documentation for importing route objects from another IRR.
How many people are affected? What kinds of places?
As part of our internal impact analysis, I have been looking at the set of objects I can identify in the RIPE Database that relate to resources held under APNIC regional management. This includes direct allocations and assignments from APNIC, and indirect resources maintained by the seven NIRs in China, India, Indonesia, Japan, Korea, Taiwan, and Viet Nam.
In July, I examined the data as I saw it, from exports of the RIPE IRR data, as RPSL ‘split’ files.
How much data?
Approximately 2,900 distinct APNIC region prefixes are represented in route: and route6: objects in the RIPE NCC database. These prefixes distribute over 385 distinct address holders, indirect (NIR sub-account) address holders, a mix of Members, and historical Non-Member resource holders.
Here’s how they are spread across economies of the region:
| Economy | Count |
| PK | 57 |
| CN | 54 |
| IN | 45 |
| HK | 40 |
| AU | 34 |
| AP | 22 |
| SG | 21 |
| MY | 20 |
| JP | 20 |
| ID | 13 |
| BD | 12 |
| NZ | 10 |
| KR | 7 |
| TW | 5 |
| PH | 5 |
| CN | 4 |
| MN | 4 |
| AF | 4 |
| MM | 2 |
| TL | 1 |
| NP | 1 |
| NC | 1 |
| IO | 1 |
| CX | 1 |
The summary here is that while there are some hot-spot economies, this is actually quite a widely distributed problem; 24 distinct economies have some kind of involvement in this process.
Let’s look at how they distribute in time.
Figure 1 — Distribution of route and route(6) objects by year last modified.
Although there are a number of objects that go back a long time without modification, including a notable spike in 2010, there are sufficient objects with only a few years’ history that indicate there is ‘current’ data being maintained in this set. Therefore, there is a continuing need for some kind of IRR process and Member engagement to help people manage their routing policy in our region.
How are people going to be contacted?
Although APNIC rarely passes up a chance for direct engagement with address holders, the primary engagement here necessarily comes from the RIPE NCC. While APNIC can see who has records in this database, it is presumptuous of APNIC as the local Secretariat to ‘reach over the wall’ and communicate with the RIPE IRR object holders, since APNIC has no direct role in how those address holders have chosen to manage their routing policy.
The RIPE NCC has already contacted the affected address holders and has shared the web page that documents how they can engage with APNIC to manage the import of foreign objects. APNIC is ready to assist the affected address holders once they have had time to review their options.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.