How Pingable are the Pingables?
The RIPE NCC has been operating the RIPE Routing Registry as part of the RIPE Database since 1995. Governed by the Routing Policy Specification Language ( RPSL ), the routing registry allows network operators to document their routes and routing policies in a public database. In August 2010, newly published RFC 5943 extended the language with two new attributes 'pingable' and 'ping-hdl'. The purpose of these attributes is to help in the debugging of common issues with (new) IP connectivity, such as reachability and Path MTU discovery. With the 'pingable:' attribute network operators can advertise an IP address that should be reachable from outside networks and can be used as a target for diagnostic tests such as ping. The 'ping-hdl:' attribute provides a link to contact information where queries concerning the specified address can be send to.
When it comes to using the new attributes RFC 5943 states:
The presence of one or more pingable attributes signals to network
operators that the operator of the target network is providing the address(es) for external diagnostic testing.
The 'pingable:' and 'ping-hdl:' attributes were implemented in the RIPE Database in February 2011. Five years later we look at how widely these attributes are used and how pingable they are, how well the addresses respond to ping tests performed by RIPE Atlas anchors . Apart from general curiosity this investigation aims to provides input to the evaluation of an item on the RIPE Atlas
The RIPE Database view
As part of routine operations, the RIPE Database publishes a full dump, split by object type, on
on a daily basis. For the purpose of the 'pingable' analysis we are looking at the dumps of
objects. On 10 March 2016 we found the following numbers for IPv4 and IPv6 respectively:
|Number of routes||281,919||14,537|
|Number of pingable: attributes||146||189|
|Number of ping-hdl: attributes||89||73|
|Unique IPs in pingable: attributes||129||160|
|Unique origin ASes||26,376||7,246|
|Unique origin ASes with pingable:||65||70|
Table 1: pingable and ping-hdls in the RIPE Routing Registry
As the table shows, only a small fraction of the IPv4 and IPv6 route objects present in the RIPE Routing Registry have a pingable attribute. The number of unique addresses registered in pingable attributes is a little lower than the number of objects. When address space is covered by more than one prefix in the routing registry (e.g. an aggregate and a more specific), we sometimes see the same IP adddress registered as 'pingable:' in more than one route object. At the level of Autonomous Systems (ASes) the relative presence of IPv4 pingable attributes is slightly higher. The 146 IPv4 route objects with a pingable attribute have in total 65 unique ASes listed in the respective origin attributes; that's 0.25% of the total number of unique ASes in route objects.
In Table 2 we look at the distribution of pingable attributes per origin AS. Most ASes that are registered as origin for routes with pingable attributes, are linked to just one or two pingable addresses. Only a handful have significantly more, the top ASes being AS12654 ( RIPE NCC's ) in IPv4 and AS198412 (Rage4 Networks Limited) in IPv6 with 20 and 47 unique pingable addresses respectively.
|Origin AS||Number of pingables||Origin AS||Number of pingables|
Table 2: Top 5 ASes with pingable attributes in the RIPE Routing Registry
Measurements with RIPE Atlas
To get an idea how well reachable the addresses listed in pingable attributes are, we turn to RIPE Atlas and more specifically the RIPE Atlas anchors
Since RFC 5943 mentions debugging issues in new network deployments as a reason for creating the RPSL pingable: and ping-hdl: attributes, we are interested to see if the non-responsiveness of a significant fraction of IPv4 and IPv6 pingables seen in the RIPE Routing Registry in March 2016 relates to the age of the attributes: are the addresses that fail to answer to ping predominantly in pingable attributes registered long (e.g. more than a year) ago? in networks that have matured and no longer need to offer a target for external testing? With little to no incentive to clean up the route objects, it is possible operators forgot to remove the pinagable attribute when tests were over and the target stopped answering to (external) pings. To assess this theory we processed the full history of the route objects in the RIPE Database and extracted the date each unique pingable address first appeared in a pingable attribute. Figure 3 shows the resulting age distributions of the IPv4 and IPv6 pingables with superimposed success and failure indicators from RIPE Atlas measurements: each bar in the plots shows how many unique addresses were added in pingable attributes to route/route6 objects in one month intervals for the past 5 years; within each bar the green part counts the number of addresses that answered to pings from at least one RIPE Atlas anchor while the red part counts the number of addresses that do not answer to ping tests from any anchor.
The graphs clearly show the absence of any direct relation between the age of pingable attribute and the corresponding address replying to pings from RIPE Atlas anchors. In IPv4 roughly equal numbers of unresponsive addresses are found in pingables of 14 months, 25 months and 61 months old respectively. For IPv6, most of the addresses registered as 'pingable:' in route6 objects between 7 and 14 months ago don't answer to ping. Older IPv6 pingables on the other hand, see a minority of addressses not responding.
Observations from RIPE RIS
As pingable attributes are intended to signal availability of specific IP addresses for external testing, one would expect the corresponding address space to at least be routed. Interestingly, the history of BGP data gathered by the RIPE Routing Information Service (RIS) shows this is not always the case. Three IPv4 and 28 IPv6 addresses found in pingable attributes on 10 March 2016 have never been seen covered by a prefix in the RIS system of route collectors and BGP peers. With no routes in BGP, it is no surprise ping packets don't reach their destination and don't receive an echo reply. Operators may have had their reasons, but it is odd to find route objects and pingable attributes in the routing registry for prefixes that have never been routed globally; especially when these objects have been in the registry for half a year or longer. It doesn't match the expectation set by RFC 5943.
We also found 12 pingable addresses (4 IPv4, 8 IPv6) that were not covered by BGP routes during the two week measurement period, but for which BGP data and Routing Registry data did show overlaps before. Although not working today, we cannot exclude these addresses answered to external ping tests in the past, when routes to the address blocks were present in the routing system.
The new attributes defined by RFC 5943 are rarely used. In March 2016 only 1% of the IPv6 and 0.05% of the IPv4 route objects registered in the RIPE Database had a pingable attribute. The addresses that are found in pingable attributes don't respond too well to ping tests. 64% of the IPv6 and 29% of the IPv4 pingable addresses attributes did not work at all from a collective of 160 RIPE Atlas anchors; all ping requests sent in a 14 day measurement period went unanswered. Moreover, some 15% of all pingable addresses were not covered by a route in BGP during the measurement period and for three quarters of these (10% of the total) we don't see any route in RIS history.
These findings illustrate the Routing Registry is not always in sync with operational reality. The simple presence of a route in the Routing Registry does not mean one can expect the route to be present in the BGP data collected by RIS. Likewise, the presence of a pingable attribute, is no guarantee the registered address will reply to ping tests from random external sources like RIPE Atlas probes. Without consulting the operators responsible for the pingable addresses, no conclusions can be drawn about full or partial failures of such ping tests. From the outside, it is just not possible to know if the addresses are supposed to (still) answer to ping or if the routers in the origin AS or their immediate upstreams are supposed to let ICMP traffic pass unfiltered. Together with the observed high failure rate, this makes it less useful for RIPE Atlas to automatically and indiscriminately ping all the addresses as 'pingable' in the RIPE Database.