An Update on De-bogonising 128.0.0.0/16

We continued RIPE Atlas measurements to see if we can still find cases where 128.0.0.0/16 is filtered out.

In The Curious Case of 128.0/16 , we looked at how much filtering of 128.0.0.0/16 is going on on the Internet. The software on some Juniper routers blocks 128.0.0.0/16 as martian, even though RFC 5735 and RFC 3330 say that this space should no longer be reserved as special address space.

As described in De-bogonising 128.0.0.0/16 , the RIPE NCC has been helping network operators to clean up these redundant settings.

The last IPv4 addresses we distributed before reaching the last /8 were addresses from 128.0.0.0/16. During this time, measurements could no longer be made even though we continued to contact those who were filtering this prefix. On request from some of our members who received addresses from this range, we re-started our measurements.

In Q3 of 2012, we started measuring this again by sending pings and traceroutes from two different sets of about 1,000 RIPE Atlas probes to two prefixes in two different Local Internet Registries (LIRs) that offered to help with this project.

Thanks to these measurements, we can now see how (failing) traceroutes to 128.0.0.0/16 compare to traceroutes to other prefixes in the same LIR's network.

Conclusions

We found that over 95% of the RIPE Atlas probes can now reach destinations addressed with addresses from 128.0.0.0/16. 64 RIPE Atlas probes failed to get a ping reply from the targeted address.

While bringing the filtering practices down to this level is already an achievement, the ideal situation would be a 0% failure rate. Even if only a few networks filter 128.0.0.0/16, it can make operations difficult for those LIRs that received addresses from this range.

Please double check that you are not filtering this prefix and that your router software is up to date. You can test this against ripe-test.my-wire.de or 128.0.168.1 and check if you get a reply.

Measurement results

The graphs below show the result of the measurements done by a set of RIPE Atlas probes to two addresses in 128.0.0.0/16 assigned to two different LIRs in different parts of the world and the Internet. To eliminate issues specific to a probe that are not related to filtering of 128.0.0.0/16, we only consider probes that were able to ping to a control address in the same LIR.

The green points show the percentage of probes succeeding in pinging the address. The red points show the number of probes failing to get a ping reply from the target. In both cases the probes were succesful in reaching the control address.

To eliminate the effects of short-lived fluctuations, success is defined as a probe receiving at least one reply from the target in a one-hour time frame.

De-bogonising Measurements 1 Figure 1: Success and failure rate of RIPE Atlas probes to target 1

De-bogonising Measurements 2 Figure 2: Success and failure rate of RIPE Atlas probes to target 1

Comments 2

Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.

Leo Vegoda • 21 Feb 2013 15:33

Mirjam, can you also publish graphs showing how these prefixes compare against more established address space? We have seen people accidentally block everything in 192/8 rather than just 192.168/16, so I expect that even long established prefixes don't reach 100% availability.

Rene Wilhelm • 21 Feb 2013 16:37

Leo, you are right that long established prefixes may not have 100% reachability either. With RIPE Atlas we also have seen probes which, for whatever reason, temporary or long term, don't receive any reply from pings to an established destination address. To help eliminate those effects, the two LIRs also provided pingable targets in 185/8 and 217/8 respectively. In the analysis and graphs above we only considered the Atlas probes which could ping those control addresses succesfully. The failures, non reachability, thus really relates to the target addresses being in 128.0/16 space.