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