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. [1]

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 [2] 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 [3], but note that some aspects of subnet addressing have altered since this RFC was written (see RFC 1878[4]), 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:

MI Number

Subnet Prefix

Network Size

Network Number

Prefix

Last Host Number

Max Host Number

(null)

00

64

0

/26

58

62

1

10

64

128

/26

177

190

01

010

32

64

/27

93

94

11

1100

16

192

/28

206

206

001 matches subnet prefix 00

101 matches subnet prefix 10

011

01100

8

96

/29

99

102

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 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’s article titled “Working with IP Addresses” was a nice refresher on
how complicated working with IPv4 addresses has become. It should remind us all how we have gotten used to dealing with the operational expense of IPv4 address
scarcity. The story about putting a frog in a pot of cold water comes to mind.

In any case, at the end of the article in the section titled “Working with IPv6 Addresses,” I think the author tries too hard to fit the IPv6 address
structure into the model for IPv4. Actually, it is a lot simpler.

The IPv6 address structure and textual representation was designed to avoid most of the complexities encountered in IPv4. The big differences follow:

Addresses are represented in groups of hexadecimal digits instead of decimal digits. Hexadecimal avoids the need to convert the decimal digits to octal to
fi nd subnet boundaries. In hexadecimal there are four bits per character. This makes it easy to fi nd the subnet boundary in an address; in many cases it is
at a character boundary.

Subnet prefix lengths are listed directly in decimal. There are no decimal subnet masks. This eliminates the need to convert decimal
addresses to octets, convert the subnet masks to octets, apply the mask, and convert the result back to decimal—or to use the table and division methods
described in the article.

The combination of these changes makes it much easier to work with IPv6 addresses. They are, of course, longer. The length has a few advantages besides a much
larger Internet.

A byproduct of the larger address space is that most of the common subnet bound aries fall on hexadecimal digit boundaries; for example, using the example
address in the article:

2002:FF10:9876:DD0A:9090:4896:AC56:0E01

The most common subnet boundary is 64 bits. The address and prefix is represented as:

2002:FF10:9876:DD0A:9090:4896:AC56:0E01/64

The subnet itself then follows:

2002:FF10:9876:DD0A::/64

The current common prefix allocated to a site is a /48. The site prefix is then:

2002:FF10:9876::/48

The current default allocation to an ISP is a /32. The ISP prefix is then:

2002:FF10::/32

These common prefix lengths can be derived directly without any need for decimal-to-octal conversions, table lookups, divisions, etc.

One of the other benefits of the larger addresses and a byproduct of IPv6 auto configuration is that the low-order 64 bits of an IPv6 address are reserved
for the host address (called Interface Identifier in IPv6 terminology). This means that “The Hardest Subnetting Problem” described in the article is avoided
completely. You can have as many hosts on a specific segment as you want in IPv6. There is no need to do this kind of calculation. This makes an initial network
design trivial and, more importantly, makes later changes very easy. There is no need to redesign a subnet architecture because a few hosts need to be added to a
subnet.

Bob brings up many interesting points about IPv6, and the use of the IPv6 address space. While most IPv6 address spaces have prefix lengths that break on
even octet boundaries today, we can’t always count on this, for all time, so it is always good to have techniques to work with situations where the prefix
length is not on an octet boundary when they do occur. As for the last problem, it is true that in all cases the subnet is the set of octets excluding the last
64 bits. But if we move the problem up one level, and ask: “What is the most efficient way to allocate out an existing /48 so customer A can get 10 subnets,
customer B can get 20 subnets, etc. ?” we can see the same problem could occur at the next higher level.