Rene Wilhelm

How Pingable are the Pingables?

Rene Wilhelm
0 You have liked this article 0 times.

In February 2011 the RIPE NCC implemented the "pingable:" and "ping-hdl:" attributes in the RIPE Database. These attributes were added to the Routing Policy Specification Language by RFC 5943 to allow networks to advertise IP addresses that are reachable and can be used as a target for diagnostic tests. Five years later we check how the new attributes have been adopted and how reachable the pingable addresses registered in the RIPE Database are when pinged from RIPE Atlas.


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 roadmap : t o extend the diversity of measurement targets, it has been suggested RIPE Atlas automatically measures the targets contained in the "pingable" attribute in route and route6 objects in the RIPE Database.

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 route and route6 objects. On 10 March 2016 we found the following numbers for IPv4 and IPv6 respectively:

IPv4 IPv6
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 Routing Information Service (RIS ) in IPv4 and AS198412 (Rage4 Networks Limited) in IPv6 with 20 and 47 unique pingable addresses respectively.


IPv4 IPv6
Origin AS Number of pingables Origin AS Number of pingables
12654 20 198412 47
49689 12 49436 38
197216 10 12654 16
49655 6 39126 8
47409 5 49655 6

  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 .   Generally situated in well connected places, we expect these  powerful probes to have little to no local problems which impair the measurements.  Compared to probes installed in home networks,  packet loss observed with the anchors is more likely to be caused by issues in transit or in the destination network rather than in the host network.

We set up measurements which at low frequency  from 160 available anchors ping all IPv4 and IPv6 'pingable' addresses registered in the RIPE Database.  For the two week period from 9 to 23 March 2016 this resulted in the order of 50,000 packets sent to each destination address.  As an indicator of global reachability, we calculate the overall loss rate in the RIPE Atlas anchor infrastructure for each pingable address. I.e. we sum up the number of ping packets received by and sent from all anchor nodes. From those numbers we then compute the percentage lost by the anchors as a whole. The resulting values are grouped in bins of 2% loss and shown in Figure 1 below.


Figure 1: Overall loss rates for the IPv4 and IPv6 pingable addresses as seen by RIPE Atlas anchors

We see the distributions are largely bimodal: most pingable addresses either work with little to no loss or they fail consistently from all probes most of the time. In numbers we find 38 out of 129 pingable IPv4 addresses and 102 out of 160 pingable IPv6 addresses never responded to pings from the 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.

0 You have liked this article 0 times.

You may also like

View more

About the author

Rene Wilhelm is a senior research engineer in the R&D department at the RIPE NCC. Coming from a background in particle physics, Rene joined the RIPE NCC in 1996. His interests are in data analysis, routing, Internet measurements and visualisation.

Comments 1