Skip to main content

Confessions of an IPv4 Conservative

June 24, 2014

An area in which I've seen IPv4 thinking influence IPv6 addressing is on the prefix allocation side. And I have a confession to make: Until recently I've been guilty of this wrongheaded thinking myself.

As a consultant primarily to service providers, I have frequently stated that "common industry practice" when allocating IPv6 blocks to customers is to use one of three assignment classes:

  • Large customers get a /48 prefix. That gives them 65,536 /64 subnets.
  • Medium customers get a /56 prefix. That gives them 256 /64 subnets.
  • Small customers (meaning home or small office customers) get a single /64 prefix.

A concern with this last class is that future applications might require subnets even in a home or small office, so a hedge would be to assign /60 prefixes, allowing 16 /64 subnets.

Here's the problem with that practice:

How do you define large, medium and small? You could say the dividing line is subnet requirements, but how are your skills at predicting the future? What happens if a customer grows from your definition of medium to your definition of large? Do you re-allocate and make them re-address their network? That's a complicated project. It sounds like a potential customer relations problem.

For that matter, why is it any of your business to decide what size networks your customers have?

Just as you should be using /64s on every subnet, why not allocate a /48 prefix to every customer site? In general a site should be a building. So if your customer occupies a single building, give them a /48 no matter how small the building is. If your customer has a campus with 30 buildings, give them 30 /48s. If your customer has 300 branch offices in your service area, give them 300 /48s.

Using a /48 as the unit of site allocation helps you avoid another imprecision: the "very large customer." It's used to mean a customer that needs an address pool larger than a /48: a /47 prefix or shorter. Presumably such a customer has multiple sites, so a /48 per site gives you a reasonably well-defined allocation guide.

Maybe a customer occupies a single very large building, and wants more than one /48. Give them what they want. Let them decide their needs, rather than trying to pigeonhole them into some arbitrary class.

And, yes, a house is a site. An apartment is a site. If you are serving residential customers, give each of them a /48.

Maybe with that last recommendation you decide to put your foot down. "A /48 for a residential user?" you say. "That's ridiculous! No home user is ever going to have 65 thousand subnets! No small office is ever going to have 65 thousand subnets!"

I think you're right. They'll never use 65,536 subnets. But how do you know that a /60 assignment providing 16 subnets is enough? In the home of the future maybe entertainment systems, security systems, communications systems, appliances, environmental and power controls and medical monitors are all on separate subnets. Maybe each member of the house has a set of all these subnets dedicated just to him or her. And these are just the services we have presently. What about all those we cannot foresee? 16 subnets are certainly not enough, but 65K should cover any eventuality.

How many subnets the household or small office of the future needs, or whether it will ever need more than one, is not really your problem. Worrying about wasting most of the 65,536 /64 subnets in a /48 prefix is the same as worrying about wasting most of 18 million trillion addresses on a single /64 subnet.

Waste is not the point, because with IPv6, address conservation becomes irrelevant in practical designs. What is important is consistency. Just as all subnets in a network should be /64, all prefixes assigned by an address management authority should be a /48 or some multiple of /48. You should only assign a /64 in the corner case where you know for sure that subnetting will never, ever be needed. Homes and small offices do not meet that criterion.

Portions of this article originally appeared in an article written for Network World titled “The Logic of Bad IPv6 Address Management.”

Related Blogs

October 20, 2015

Check Point Kernel Debugging, In-Depth

The following is a look into the features and inner-workings of debugging the Check Point firewall kernel. This information will prepare you to debug ...

See Details

June 01, 2015

Vulnerabilities in Bluecoat SSL Visibility Appliances

Last Friday, Bluecoat and CERT published security advisories for vulnerabilities in the administrative interface of the Bluecoat SSL Visibility Applia...

See Details

May 04, 2015

How Not To Prevent CSRF in a RESTful Service

Last Friday, Bluecoat and CERT published security advisories for vulnerabilities in the administrative interface of the Bluecoat SSL Visibility Applia...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.

Privacy Policy

Related Insights

August 24, 2017

Enterprise Incident Management Brief

Learn how Optiv’s workshop helps security leaders evolve their technical incident response practices to broad scope enterprise incident management.

See Details

May 03, 2010

MPLS - The Forgotten Enterprise Technology

There is a common misconception that MPLS (multi-protocol label switching) in the enterprise is akin to killing flies with a bazooka: it’s costly, its...

See Details

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.


Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cyber security Events in your area.