An Update on De-bogonising 128.0.0.0/16

Mirjam Kühne — Feb 21, 2013 01:45 PM
Contributors: Kjell Leknes, Rene Wilhelm
Filed under: , ,
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 1Figure 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

 

 

2 Comments

Leo Vegoda
Leo Vegoda says:
Feb 21, 2013 04:33 PM
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
Rene Wilhelm says:
Feb 21, 2013 05:37 PM
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.
Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Navigation
Related Items
Increased Reach of RIPE Atlas Anchors

Increasing the reach of RIPE Atlas anchors is one of the highest priority goals of RIPE Atlas Team. ...

Proposing Making RIPE Atlas Data More Public

RIPE Atlas is now three years old, and is moving from a prototype to production service. Based on ...

RIPE Atlas: Improved Probe Pages

We've made it much easier to get an overview of the history and measurements for all the public ...

Visualising Bandwidth Capacity and Network Activity in RIPEstat Using M-Lab Data

As a result of the cooperation between the RIPE NCC and Measurement Lab (M-Lab), you can now ...

RIPE Atlas Fun: Map a RIPE Atlas Anchor

View maps based on RIPE Atlas traceroute measurements. Compare the maps to the ISP's description of ...

more ...