De-bogonising 128.0.0.0/16

Kjell Leknes — Jun 15, 2012 10:10 AM
Contributors: Kjell Leknes
Filed under: ,
Please find below an update of our effort to help network operators clean-up redundant settings with respect to 128.0.0.0/16

In The Curious Case of 128.0/16, we looked at three ways to get a rough estimate on 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.

The RIPE NCC is currently helping network operators to clean-up these redundant settings. As an effort to support our community, we hope this will have noticeable improvements on global routing.


Over the past few months the RIPE NCC helped network operators by making them aware of this issue and suggesting to fix it, so we can start allocating and assigning address space from 128.0.0.0/16. We used RIPE Atlas to investigate where filtering is happening.

On 9 February 2012, the RIPE NCC started contacting those network operators we could measure via the RIPE Atlas probes that were still filtering this prefix. The results are described in 128.0.0.0/16 as Seen by RIPE Atlas. Consequently, we contacted 121 operators. These covered the entire list of instances were RIPE Atlas probes encountered filtering.

Many operators represented more than one instance of filtering. From this initial round, 37 operators were aware of the issue. Fifteen told us they were not aware of the issue. And the remaining operators were unresponsive. Thirty-four operators confirmed they would update their filters within one month. Many of these confirmed that they had immediately done so upon receiving our request.

Only two operators needed some more time to implement the changes. After only two months, we could see a noticeable decrease in the amount of filtering this prefix: 47 operators stopped filtering prefixes within 128.0.0.0/16. We expect these numbers to improve as one operator represented 65 instances of filtering. They were the first ones we contacted, and they confirmed that they only need one month to resolve it.

After the first round, we could measure an improvement from ~70% to ~85% of RIPE Atlas probes reaching the debogon prefixes in 128.0.0.0/16 as you can see in the image below.

RIPE Atlas probes reaching 128/16Figure 1: Percentage of RIPE Atlas probes that can reach 128.0.0.1, 128.0.24.1


We tried phoning and emailing the operators, but realised early on that most operators preferred to be contacted by email at their public NOC addresses. After receiving such feedback at the start, we altered our approach. The operators with clearly defined NOC email addresses were only approached by email. And we phoned smaller operators for which we didn't have clear contact information. Overall the response has been positive. People appreciated being informed and instructed on how to resolve the problem.

0 Comments

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
Modifications to the IP Analyser to Reflect New Policy

We are in the process of implementing the policy regarding Post Depletion Adjustment of Procedures ...

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 ...

Valuing IP Addresses

The prospect of exhaustion of the IPv4 address space is not a surprise. We've been anticipating ...

The Assisted Registry Check - Let Us Help You!

The Assisted Registry Check is the new name for the RIPE NCC’s audit activities that have been ...

IPv6 Darknet Experiment

Similar to an experiment done for IPv4 address space, Merit is now performing a darknet experiment ...

more ...