Resource Public Key Infrastructure (RPKI) has become a popular infrastructure for the certification of assigned and allocated IP address and Autonomous System Number (ASN) resources. If you are a resource delegate, or network operator and actively configuring Border Gateway Protocol (BGP) in the ISP and content delivery spaces, you might have already registered Route Origin Authorizations (ROAs) and deployed BGP route filters based on RPKI-based checks called RPKI Route Origin Validation (ROV).
Internet Exchange Points (IXPs) operate their own assigned and allocated networks; we call this the ‘IX segment’. The IX segment is an important network as a peering platform. Every participant in the IX is assigned IP addresses on this IX segment and uses them to connect to each other over the IX fabric (the switching layers, be they on copper or fibre). Because there are many eBGP sessions between ASes used for exchanging their traffic, it’s important that this segment is protected from mis-origination of BGP from the peerings operated in this IX (Figure 1).
I surveyed the status of RPKI ROA registration for IXPs operating in the Asia Pacific region and several IXPs in the European region on 17 February 2023. My first impression is that both regions lack a sense of unity, with RPKI ROA registration being inconsistent.
The survey revealed that there are clearly two types of IXPs — one has registered ROAs, and the other hasn’t (yet). Perhaps this divide is because issuing ROAs for IP resources in the IX segment is a relatively new thing. But among IXPs that have already registered ROAs, there are also some notable differences in the status of registration. As Tables 1 and 2 show, one point of difference is the registered prefix size inside the ROA (exact match and longest prefix match), and another difference is the ASN used for ROA registration.
IX name | IP Prefix for IX Segment | ROA |
BBIX Tokyo | 2001:de8:c::/64 | None |
BKNIX | 2001:deb:0:68::/64 | 2001:deb::/48, maximum prefix length = /48, AS63528 |
Equinix Singapore | 2001:de8:4::/64 | 2001:de8:4::/64, maximum prefix length = /64, AS0 |
GetaFIX Manila | 2401:fdc0::/64 | None |
HKIX | 2001:7fa:0:1::/64 | 2001:7fa:0:1::/64, maximum prefix length = /64, AS0 |
IIX-Jakarta | 2001:7fa:2::/64 | None |
IX Australia (Sydney NSW) | 2001:7fa:11:4::/64 | None |
JPNAP Tokyo | 2001:7fa:7:1::/64 | 2001:7fa:7::/48, Maximum prefix length = /128, AS0 |
KINX | 2001:7fa:8::/64 | None |
MegaIX Sydney | 2001:dea:0:10::/64 | 2001:dea:0:10::/64, Maximum prefix length = /64, AS0 |
MyIX | 2001:de8:10::/48 | 2001:de8:10::/48, maximum prefix length = /48, AS55822 |
NIXI Mumbai | 2001:de8:1:1::/64 | None |
SGIX | 2001:de8:12:100::/64 | None |
TPIX-TW | 2406:d400:1:133:203:163:222:0/112 | None |
LINX LON1 | 2001:7f8:4::/64 | None |
AMS-IX | 2001:7f8:1::/64 | None |
DE-CIX | Frankfurt 2001:7f8::/64 | None |
JPIX TOKYO | 2001:de8:8::/64 | 2001:de8:8::/64, maximum prefix length = /128, AS0 |
Table 1 — RPKI ROA Survey (IPv4).
IX name | IP Prefix for IX Segment | ROA |
BBIX Tokyo | 218.100.6.0/23, 101.203.88.0/22 | None |
BKNIX | 203.159.68.0/23 | 203.159.68.0/23, maximum prefix length = /23, AS0, 203.159.68.0/23, maximum prefix length = /23, AS63529 |
Equinix Singapore | 27.111.228.0/22 | 27.111.228.0/22, maximum prefix length = /24, AS0 |
GetaFIX Manila | 103.104.19.0/24 | 103.104.16.0/22, maximum prefix length = /24, AS137074 |
HKIX | 123.255.88.0/21 | 123.255.88.0/21, maximum prefix length = /21, AS0 |
IIX-Jakarta | 103.28.74.0/23 | None |
IX Australia (Sydney NSW) | 218.100.52.0/23 | 218.100.52.0/23, maximum prefix length = /23, AS0 |
JPNAP Tokyo | 210.173.176.0/23 | 210.173.160.0/19, Maximum prefix length = /32, AS7521 |
KINX | 192.145.251.0/24 | 192.145.240.0/20, Maximum prefix length = /24, AS14828 |
MegaIX Sydney | 103.26.68.0/23 | 103.26.68.0/23, maximum prefix length = /23, AS0 |
MyIX | 218.100.44.0/24 | 218.100.44.0/24, maximum prefix length = /24, AS55822 |
NIXI Mumbai | 103.156.182.0/23 | None |
SGIX | 103.16.102.0/23 | None |
TPIX-TW | 203.163.222.0/24 | 203.163.222.0/23, maximum prefix length = /24, AS10133 |
LINX LON1 | 195.66.224.0/21 | 195.66.224.0/19, maximum prefix length = /19, AS5459 |
AMS-IX | 80.249.208.0/21 | 80.249.208.0/21, maximum prefix length = /21, AS1200 |
DE-CIX Frankfurt | 80.81.192.0/21 | 80.81.192.0/21, maximum prefix length = /21, AS0 |
JPIX TOKYO | 210.171.224.0/23 | None |
Table 2 — RPKI ROA Survey (IPv6).
Both IPv6 and IPv4 share similar results within IXPs.
Types of ROA registration
The types of ROA registration can be classified into three groups.
- ROA prefix size: There are two types — exactly matching size and larger size. A larger size means that an IXP operates a /24 IX network but has a /23 prefix assigned or allocated, and registered in their RPKI ROA.
- ROA maximum prefix length: This also has two types — one of these has equal length, and the other has a maximum prefix size longer than the prefix size.
- ASN used for ROA registration: Again there are two types — one type is using AS 0, and another is using your own ASN.
The use of AS 0 in RPKI is described in RFC 6483 which defines the semantics, in general, of ROAs. An important point to note is that prefixes registered with AS 0 in an RPKI ROA should not be used in a routing context without a more specific ROA which denotes the origin-as other than AS0. In other words, you should use AS 0 as the ASN for a prefix that isn’t to be seen on the global routing table when registering ROAs. So, If an IXP has created an RPKI ROA for the IX segment, the RPKI ROA of the IX segment can be checked by ISPs using RPKI ROV, thereby preventing trouble due to mis-origination advertisement because mis-originated routes will be seen as invalid and not received on ISP border routers as there will be no other ROA with another origin-as apart from AS0.
It is most important to issue ROAs with the correct prefix size, maximum prefix length, and ASN. If you have registered ROAs without these, the ROA will not prevent mis-origination if they specify prefix lengths that are not blocked by the ROA. Equally, manual route filter configuration is still necessary; don’t forget to keep your PeeringDB and Internet Routing Registry (IRR) entries up to date.
As this survey has shown, a wide variety of RPKI ROAs have been issued in the IXP segment but we can suggest two best practices — properly issue ROAs with AS 0 and the correct maximum length (for both IPv4 and IPv6), and if your IXP has already issued ROAs, please check whether it has AS 0 and the correct maximum length.
Correctly issuing ROAs help to secure global Internet routing. It’s time for the IX segment to do it properly.
Masataka presented this during the APRICOT 2023 Peering Forum 3. Watch the session now:
Masataka Mawatari is an engineer at JPIX in charge of IX network operations, route servers, and IPv6 deployment. He contributes to JANOG and the other network engineer communities.
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.