Letters to the Editor - The Internet Protocol Journal - Volume 9, Number 2

Dear Editor,

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 Friedman, Sydney, Australia

Ed: Readers may wish to also peruse RFC 3531 [5].

[1] P. Ferguson and H. Berkowitz, â€Å“Network Renumbering Overview: Why Would I Want It and What Is It Anyway?â€ï¿½ RFC 2071, January 1997.

[2] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, â€Å“Address Allocation for Private Internets,â€ï¿½ RFC 1918, February 1996.

[3] P. F. Tsuchiya, â€Å“On the Assignment of Subnet Numbers,â€ï¿½ RFC 1219, April 1991.

[4] T. Pummill and B. Manning, â€Å“Variable Length Subnet Table for IPv4,â€ï¿½ RFC 1878, December 1995

[5] 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

Dear Editor,

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:


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


The subnet itself then follows:


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


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


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 Hinden, Nokia

The author responds:

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.

—Russ White, Cisco Systems