In the past year, we completed an unusual transaction where a small block of 256 addresses sold for over $1500 per address.  That’s right.  This buyer was a long-time ISP customer of the seller and had been using this block for years.  When the seller asked the buyer to return that block so they could sell off the larger block that it was part of, the buyer began negotiating in earnest so they could retain it.

It’s likely that there were only a few important individual addresses within that /24 that held the extraordinary value to the buyer. Were they “vanity” or easy-to-remember, like  No, these addresses held value because vital old applications with hardcoded IPv4 addresses had spread throughout the world, and the cost to re-write or replace these applications was prohibitive.

Still, that’s not unheard of, and we have come across this situation before. For example, where a customer makes a deal with their ISP to buy a block they’ve had assigned to them by the ISP for decades. It’s often much cheaper than renumbering even if the buyer pays above market rate. We are often surprised at the old systems that just keep running while their programmers retire and the current IT staff are generations behind the people who created these things. There are other reasons, too. Sometimes it’s hard to access devices with static IP addresses that need to be changed. Imagine remote sensors in Antarctica, or devices with lost configurations and passwords that keep plugging along. Just don’t’ try to change them.

That doesn’t mean thirty times the market rate, though. What was the issue here that made it a fair price?

Pricing of Smaller Blocks vs. Larger Blocks of IP Addresses

The issue was the strange price difference that exists today between smaller blocks and larger blocks. Whereas in the past it paid for sellers to break down a /16 and sell it in small sizes to reap the benefit of a higher average per-address price, today sellers are scrambling to assemble /17s and /16s in order to reap these inverse economies of scale.

In the past, the IPv4 market incentivized de-aggregation of larger IPv4 blocks into smaller ones. This is undesirable because it causes the routing table to grow. But the current strange situation actually works in reverse of that incentive because today the market incentivizes putting Humpty Dumpty back together at all costs.

The Deal

Today we received an offer from another broker offering to sell blocks at $49 per address for a /17 and $35 per address for a /22. It wasn’t a particularly notable offer, and that is why this /24 sold for over $1500 per address.

The /24 that the customer was using prevented a substantially larger block from being assembled and sold at the premium price. For want of that /24 the seller, could not reach that /17 threshold where pricing inflects and thus could not realize the large difference in proceeds that comes from selling 32,768 addresses for up to $14 more per address than otherwise.

The Buyer’s Decision

There was no contract in place between the seller and the buyer that prevented the seller from simply removing the assignment unilaterally and coming to market with the /17. So, the buyer had to decide if retaining the /24 was worth the difference to the seller between selling a /17 and selling smaller pieces, and, ultimately, the decision was that it was worth it to them to compensate the seller for that disparity via a contract to purchase the vital /24.

Although it would be expected to apportion blame to the buyer for failing to update things in a timely fashion, in reality, the current IT staff understood the issue was their inability to change these applications but in turn pointed to regulatory changes that among other things blocked access to their programmers and required substantial changes in other ways if the code lost the “grandfathered-in” status. So, the final sale price was based on the market disparity, which we were called upon to estimate to the satisfaction of both parties. When the unusual situation presents itself, it’s good to have IPTrading available!