Someone on a mailing list asked recently “What’s the best practice for IPv6 addressing?” The question got me thinking, and I thought I’d share some useful guidelines.
At the moment there are no real best practices. You can’t have a best practice until enough people have tried enough different things for some of those things to have emerged as the “best” ways. That means lots of people have to have succeeded, but equally a lot of people have to have failed – both kinds of activity contribute to developing “best practice”.
Which means that at this period of history the best advice, really, is to get out there and do your best. Read articles like this one, then make your own considered judgements. Hopefully you will do well, and your network will become a shining beacon of wonderfulness. But it is just as useful if, a few years from now, people point at the smoking wreckage of your network and murmur in hushed tones to their junior network techs “don’t do that”. Of course, it’s not so useful to you.
Here are some Golden Rules which I have found worthy. Perhaps you will too. They are in rough order of importance. If you have other words of wisdom, please leave a comment; I’d love to hear your thoughts.
By the way, there are two very different kinds of subnet! A leaf subnet contains actual hosts; a structural subnet is one that just divides your network up, whether for technical or administrative reasons. This article is mostly about structural subnetting.
Golden Rule 1: Count subnets, not addresses
In IPv4, when someone asks for a new leaf subnet, the first question is “how many hosts”. That question disappears in IPv6. All leaf subnets should be /64 subnets, and with 18 billion billion addresses available in such a subnet, there are enough for any conceivable need.
In a /64 subnet, it doesn’t matter whether you have 2, 20, 200 or 2000 hosts; you have still, to about nine decimal places of accuracy, used 0% of the address space. IPv6 addresses are impossibly abundant; do not be worried about wasting them.
Subnets themselves, on the other hand, are far more sharply limited. They are generally numbered in the tens of thousands, not the billions. A typical site with a /48 network, using /64 leaf subnets, has only 16 bits available for subnetting, making for 65536 subnets. Now, 65536 is a very large number of subnets, but it isn’t billions.
Golden Rule 2: Don’t overload address bits with non-addressing information
Because of the enormous address space, people often want to encode things in it – like building numbers, VLAN numbers, or what the purpose of an address region is.
One variant of this is when people want to encode existing IPv4 addressing structures into their IPv6 addressing. You might say, “well hang on, that’s not non-addressing information!”, but it is. As far as IPv6 is concerned, IPv4 is a foreign country; there is no necessary connection between one addressing scheme and the other.
Any two systems which have no necessary technical link will inevitably diverge. When they do, the encoding will be a bugbear to maintain. Worse, it may become impossible to maintain, and start lying to you. Or, worst of all, you may (consciously or unconsciously) start to make design decisions based on retaining the ability to maintain the encoding.
The encoded information assumes an importance it probably does not have – this is especially true for schemes that encode IPv4 addresses into IPv6 addresses. Why should the IPv6 addressing follow the IPv4 addressing unless the designer thinks that the IPv4 addressing has precedence?
You will inevitably allocate too few bits for the encoding – either because you forgot something or because circumstances change. If you set aside two bits to encode the four floors your company occupies in their headquarters, what happens when the company expands and takes over the fifth floor as well? No matter how many bits you set aside, you cannot be sure it will be enough. If you set aside four bits, to allow for 16 floors, what happens when the company buys a second building with 9 floors? Sure – there are enough bits, but now you need one bit to discriminate between the two buildings, and that leaves only three bits for the floors. Or do you treat both buildings together as one logical building with floors numbered zero through 12? Hmm.
Many encoding systems are wasteful. If you encode four-digit VLAN numbers into a four-digit IPv6 address group, for example, you are using a space that could contain 65536 distinct values to contain just 10,000 – a loss of about five sixths of the available address space.
Most encodings are trying to make life easier for human readers of IPv6 addresses. The aim is for them to be able to easily see where an address belongs in the scheme of things. This aim is laudable, but not when it interferes with the technical efficiency and long-term manageability of the address space.
Another tempting form of encoding is to encode the type of address into the address itself, usually for filtering purposes. The logic goes like this: “If we use one bit to identify a management address, then we can filter on that bit to protect our management networks”.
Unfortunately you have the same difficulty here as with the above example with floors. Allow for (say) four different types of address, and you will be stuck when someone invents a fifth type. If your divisions are along organisational lines, you will forever be chasing a moving target as the organisation changes, and new divisions arise, merge or disappear.
Also, many filters filter effectively only on contiguous prefixes. That means you need to use the highest-order available bits for this purpose. Unless you are lucky enough for the address type hierarchy to exactly mirror your actual network hierarchy, you will end up with very complicated filter sets all over your network.
Golden Rule 3: Keep the network as flat as reasonably possible
Every new level you introduce in your network hierarchy at least halves the number of subnets available in each branch. While addresses are cheap in IPv6, subnets are not so cheap.
Also, the more levels you have, the deeper your hierarchy and the more likely it is that you will find an entity that doesn’t fit the hierarchy, or that fits in two or more places.
As with the next rule, there will be technical imperatives that force some new levels, but unless you have a strong reason to do so, resist the temptation to add new levels of hierarchy for purely administrative reasons.
Golden Rule 4: Don’t tie network topology to geography
I use “geography” here in the broadest sense, to mean “the physical world”. In a way, this is the same rule, and for the same reasons, as Rule 2.
The reason for avoiding tying your network topology to the physical world is that networks move and flex all the time, and so too does the physical world. Companies change cities and countries, buy extra buildings, occupy more floors, open new branches, move to new buildings with different floor plans.
Building your network topology on these shifting sands means that every time they shift, either your address schema moves further away from reality, or you have to spend time adjusting it to the new reality. If you chose poorly at the start, it may not be possible to adjust it easily. If the change is minor there is a temptation to leave it “just for now” – and your address schema starts lying to you.
Every network designer will have a different physical world to work with, different physical constructs that he or she will be tempted to mirror in the network topology. Whatever they may be, it should be avoided unless absolutely necessary.
Aggregation requirements are one technical need that cannot be avoided, so this rule is always broken eventually. If you have branches in three states, for example, it is almost inevitable that the natural and correct network topology will have three “legs”, one for each state, and that the subnets for each state should come out of distinct address ranges (structural subnets).
Moving something from one structural subnet to another requires renumbering. You probably want to avoid that. So while it may be necessary to have structural subnets for the states, it is less likely that a structural subnet will be needed for each building and quite unlikely that you want a structural subnet for each floor of each building.
Golden Rule 5: Avoid exceptions
Murphy’s Law will break this rule for you soon enough, but in general you should try for a design that permits all your subnets, everywhere, to look the same, and be managed the same way. The more homogeneous your network is, the easier it is to manage and maintain.
If an exception is absolutely necessary, it should be strictly contained and very well documented.
These rules are not really IPv6-specific. It’s just that in the IPv4 world, we often can’t follow them, because the technical requirements of the cramped address space drive us towards particular, unavoidable solutions.
With IPv6, the rules gain new currency because we can mostly follow them. There will always be good technical reasons to break some of these rules some of the time. But by following each rule as far as possible, and delaying the point where it must be broken, you will end up with a more flexible, future-proof, error-proof, extensible address plan.
[This post is copied from my personal blog, where it was originally posted on 2 November 2012]