In Russ Whiteâ€™s â€Å“Working with IP Addressesâ€ï¿½ article (IPJ Volume 9, Number 1), he presents an example subnetting problem (â€Å“The Hardest Subnetting Problemâ€ï¿½) together with a worked solution. While useful as a reinforcement exercise for the rest of the article, care should be exercised before using the steps in the solution â€Å“as-isâ€ï¿½ in a real-world network configuration.
The main problem is that by packing subnets tightly together as shown, growth is restricted in order to guarantee that no address space is wasted. Worse, growth of host numbers on all but the smallest subnet requires renumbering of the subnet or all the smaller subnets allocated after it.
For example, the /26 subnet with 58 hosts will not accommodate more than another four hosts, less than 10-percent growth, without being renumbered.
Since renumbering a network is a nontrivial task even with the tools at our disposal, it is desirable to make it as infrequent as possible. 
Allowing for growth will likely but not necessarily waste some address space, but it is preferable to frequent renumbering. It turns out that this example has alternative arrangements of subnets that would permit growth of some subnets without the need to renumber and would lessen the amount of renumbering when it is required.
Using realistic estimates of future hosts rather than current numbers is a simple measure to decrease the frequency of renumbering required. This would also make it obvious that the entire allocation is close to exhaustion and can be exhausted by the need to accommodate as little as six hosts on two subnets that are near full capacity.
Constraints on the supply of IPv4 address space limits how much growth can be accommodated and requires taking a shorter-term rather than longer-term view of growth. For private RFC 1918  IP allocations (such as the one used in the example), this applies in only very large organisations, allowing a long-term view to be accommodated.
Unfortunately, the future is hard to predict with any degree of accuracy. In most cases needs for subnet allocation become gradually known over time rather than all at once. The consequences of incorrect estimation can be minimised by using an allocation scheme that allows for as much growth as possible in existing subnets while leaving as much room as possible for future allocations.
This scenario can be achieved by distributing the subnets evenly, weighted by size, across the available address space. The larger the subnet, the more room that needs to be left between it and other large networks. This is particularly important for subnets that are near to capacity. At least the sum of the sizes of neighbouring networks should be allowed. Space close to a network should be reserved for it to grow into, and the remaining space between can be allocated to smaller networks in a recursive fashion. Any allocations in the areas of likely growth should be reclaimable, and preferably these networks should be sparsely populated in order to limit the impact of re numbering on these networks. Working with a diagram of the address space, for example, a linear graph or a binary tree of the address space is a helpful aid.
A more systematic way of distributing the subnets evenly is to use mirror-image (MI) counting for allocating subnet numbers. This process is described in RFC 1219 , but note that some aspects of subnet addressing have altered since this RFC was written (see RFC 1878), so the description of mirror-image counting there and procedure text exclude subnet numbers that are now valid.
Using mirror-image counting is like normal counting starting from zero, except that the binary digits of the number are reversed. These numbers can be allocated as subnet numbers, starting from the most significant bit. Contrary to the example in RFC 1219, leading zeros (including the solitary zero in zero itself) should always be removed before the number is reversed.
Simplifying greatly, new subnets are allocated by incrementing the subnet number until a number is reached where a subnet of the required size can be accommodated or the subnet prefix becomes so long no subnets of the required size remain. If the prefix matches a common but shorter prefix, the subnet may be able to be allocated if we can lengthen the mask of the matching subnet prefix, freeing space from a previous allocation by reducing its maximum possible size. If the longest mask is always used when allocating subnets it is sufficient to just to skip matching prefixes. Note that the null prefix is common with all subsequent prefixes until its subnet mask is made smaller, extending the prefix.
The mask chosen is preferably the longest for the required subnet sizeâ€”but can be as short as the length of the subnet prefix, because it can be adjusted later: made shorter if the subnetwork grows beyond its mask (if no later allocation has been made) or longer if a subnet sharing its prefix is allocated or increases size. The host number ignoring the subnet part must be allocated from 1.
As the number is incremented it grows from right to left, progressively enumerating subnets in smaller sizes. Since subnet numbers grow from right to left and host numbers from left to right, collision is delayed between the two. Allocating subnets in descending order of size is preferable in this procedure because it tends to reduce fragmentation of the address space.
The following table shows an example allocation using the sorted number of hosts in the example:
Note that the /28 and the /29 can grow simply by changing their netmask. A better allocation is possible if the third and fourth hosts in the sorted list are inter changed. In this case the three smallest networks would be able to grow without renumbering. Shortening a netmask is a much simpler operation than renumbering.
Of course in the real world, needs for subnet allocation do not conveniently arrive sorted in ascending order. If it happened that one of the two largest subnets was the fifth requiring allocation, fragmentation of the address space would require renumbering one of the three smallest networks to recover an address block of the necessary size.
Another point that may be worth mentioning is that most modern hosts and routers allow for multiple subnets to share the same physical subnet, allowing two smaller subnets to cover a range of addresses that would otherwise receive a single larger allocation. For example, a 40-host subnet can be allocated a /27 and a /28 rather than a /26.
â€”Andrew Friedman, Sydney, Australia
Ed: Readers may wish to also peruse RFC 3531 .
 P. Ferguson and H. Berkowitz, â€Å“Network Renumbering Overview: Why Would I Want It and What Is It Anyway?â€ï¿½ RFC 2071, January 1997.
 Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, â€Å“Address Allocation for Private Internets,â€ï¿½ RFC 1918, February 1996.
 P. F. Tsuchiya, â€Å“On the Assignment of Subnet Numbers,â€ï¿½ RFC 1219, April 1991.
 T. Pummill and B. Manning, â€Å“Variable Length Subnet Table for IPv4,â€ï¿½ RFC 1878, December 1995
 M. Blanchet, â€Å“A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block,â€ï¿½ RFC 3531, April 2003.
The author responds:
Andrew is correct in stating that it is often better to try to account for future growth when assigning address space. There are many viable ways to allow for growth when allocating address spaces; hopefully, this topic will be covered more fully in a future article. I used the method in the article to illustrate how to employ the technique for working with IP addresses, rather than as an absolute best practice for allocating addresses.
â€”Russ White, Cisco Systems