How Pingable are the Pingables?

Introduction

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 ftp.ripe.net 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:

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.

  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.

Figure 1 may give the impression IPv6 is doing less well than IPv4.  The minimal loss rates in Figure 1b are higher than those in Figure 1a; not a single measured IPv6 address has an overall loss of less than 2%. However, since the graph shows the aggregate over all anchors, it cannot tell if IPv6 pings experience more loss from all anchors or if an otherwise comparable performance is degraded by a few anchors which, contrary to expectations, have problematic IPv6 connectivity. A full analysis of how IPv6 compares to IPv4 in RIPE Atlas anchors is out of scope for this analysis, but a first look at the underlying data did reveal one of the anchors (located in Indonesia) completely lost its IPv6 connectivity on 8 March 2016. All IPv6 pings to and from this anchor, including the measurements to the IPv6 addresses in pingable attributes, have failed since. This means that before results from other anchors are even added, every measured IPv6 pingable address starts with an overall loss rate of 0.65%  in the system of RIPE Atlas anchors.

Figure 1 also shows, both in IPv4 and IPv6,  a handful of pingable addresses with between 20% and 60% loss in the aggregated results. Some of these addresses are part of RIS Routing Beacons : as the route to the pingable address is withdrawn and announced at regular intervals,  ping packets only make it to the destination in about 50% of the cases. Figure 2a illustrates this. Other pingable addresses with partial reachability are more bimodal in nature: from some anchors pings always work, from others they always fail to get a response. These may point to ICMP filtering in networks not too far from the destination IP address. Anchors for which the path to the destination IP address involves such a (for pings) problematic component will always fail to receive the ICMP echo reply packet, anchors for which packets do not cross such networks will usually get an echo reply,  give or take the occasional odd packet loss e.g. due to congestion.

A special case is formed by the RIS routing beacon 84.205.72.0/24 and its pingable address 84.205.72.1. This beacon aims to simulate anycast failover: the prefix is announced permanently from the RIS route collector in Palo Alto and anncounced/withdrawn at two hour intervals from a route collector in Amsterdam. When only the route to Palo Alto is present in BGP, all ping measurements from the anchors fail; when routes to both Palo Alto and Amsterdam collectors are present, the 127 anchors that prefer the route to Amsterdam get a response, while the others continue to fail. Averaged over the entire two-week period this resulted in an overall loss of 60% in the RIPE Atlas anchor infrastructure. The distribution of loss rates observed by each individual anchors (Figure 2b) for this specific ping measurement illustrates this behaviour. We see two peaks, one centered around 50% loss representing all  anchors which, when the beacon is on, reach the collector in Amsterdam and one at 100% that represents the anchors that always try to get a response from the, for ICMP unreachable, route collector in Palo Alto.

Figure 2: Distribution of loss rates from the RIPE Atlas anchors to two 'pingable' addresses in current RIS routing beacons . Each bar shows the number of anchors with observed packet loss rates in intervals of 5% loss. Figure 2a (left) shows the results for a normal beacon, figure 2b (right) shows the results for the beacon that simulates anycast fail-over.

Correlations with age?

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.

Figure 3: Age distributions with  success / failure indicators of ping tests to'pingable' IPv4 and IPv6 addresses.

 
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.

Conclusion

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.