To Squat or not to Squat?

By Cathy Aronson - ARIN AC Member

Cathy Aronson’s crash course in ISPs adding to RFC 1918 space with unrouted IPv4 address blocks.

Recently I got an email from a colleague at a sizable ISP. He said his boss wanted to know whether it was safer to use or for additional RFC1918 address space.

I have to say I was shocked. I thought maybe I didn’t understand him. I rewrote back, “Are you saying that you are going to use and as additional RFC 1918 space?” His answer, “Yes”. I was shocked. I did not know this was happening. Certainly this had to be an isolated incident? It is an incredibly bad idea for so many reasons that I’ll talk about as I go on here.

Since I was on my way to IETF 94 in Yokohama the next week I decided to look into this matter and see who is doing this. A number of people talked candidly to me about this situation.

Before I left on my trip I did some googling to see what I could find out there on the net about this. I have attached some links below. It amused me that a large number of folks out there are seeing these addresses in their traceroutes and thinking it’s government surveillance. Of course that’s not at all the case. The not so amusing part of my googling was that there is a lot of this squatting happening out there on the net.

It turns out there are a LOT of organizations considering squatting on other organizations address space. Some of them include large ISPs, cable providers, and large enterprises.. The blocks used are not just and but there are discussions (see links below) of companies using and

I talked to another colleague at a large enterprise that is currently using He heard that the UK Government (the block belongs to the UK Ministry of Defense) may soon sell their rights to this block and it will be globally routed. There are folks trying to persuade the UK government to not sell, but it worth a tidy sum of money.

So why is this a bad idea? It is a bad idea because someone else holds rights to these blocks. If the rightful entity decides to route them or transfer them to someone else who then routes them, then everyone has a problem. The network that is squatting will not be able to get to the legitimate users of the block. The legitimate user of the block will not be able to get to a sizable number of eyeballs on those squatting ISPs’ networks.

How likely is this problem to occur? I would think that due to IPv4 address exhaustion it will become likely that some of these blocks will end up in the global routing table. For a while IPv4 address blocks will be worth quite a bit of money and it will be tempting for owners of such blocks to transfer them to whoever is willing to pay the most.

When a block like this becomes routed globally any ISP who is squatting on the space has to quickly renumber a large number of devices. This is not a trivial amount of work. That time would be better spent connecting all these internal devices via IPv6.   At least one ISP I talked to said they were using some squat space as an interim step until all the devices could do IPv6. I am not sure why others are not spending their time and energy deploying IPv6, but they are setting themselves up for a major crisis in the future.

Links of discussions of this squatting:

These are about

These are about

These are about

Some other providers who are doing this:


Cathy AronsonCathy Aronson has been an active ARIN participant since 1998. Cathy was also on the original ASO Address Council.  Cathy acts as an advocate for address policy by volunteering to do many presentations to get involvement of other communities such as NANOG.  She feels that cross pollination of ARIN with other RIRs as well as ARIN with other networking groups is essential to making good address policy. Cathy was most recently a network engineer at Cascadeo Corporation where she helped manage addressing and routing for a number of clients.

Previously, Cathy was a member of the technical staff at Packet Design, where she was responsible for operational aspects of their Internet scaling projects. Earlier Cathy was at the @Home Network where she was responsible for routing and IP addressing. She began her career at Merit, Inc. where she worked on the NSFNET Backbone. Cathy designed and implemented the OSI/CLNP for the Energy Sciences Network. Although OSI/CLNP was never widely deployed, the experience has given greater insight into addressing and scaling issues. Cathy joined the Advisory Council in June 1998 first serving an interim six-month term before being re-elected later that year to a three-year term. She was re-elected to the AC in 2001, 2004, 2007, 2010, and 2013. Her term expires 31 December 2016.




Cathy Aronson

ARIN AC Member
Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.