- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Do You Really Need a Subnet Calculator for IPv6?
You may be familiar with the anecdote about a frog placed in warm water that is brought up to a boiling temperature so slowly he does not perceive that he is being cooked. However, if the frog was put directly into boiling water he would immediately notice and jump out of the pot. Similarly, many of us have not noticed the gradual increasing complexity in IPv4 subnetting. IPv4 addresses have become increasingly scarce, resulting in increased address fragmentation and increased use of Network Address Translation (NAT). This change has occurred over decades so we barely even noticed. Similar to the frog’s situation, if we were to look at the current IP addressing difficulties with a fresh perspective, we would be shocked with how complex subnetting has become.
Today, IPv4 networks have become “sliced and diced” to the point where we end up with brain-damaging prefix lengths like /28 and /29. For example, if we need to figure out what the first and last addressable IPv4 addresses are for a /29 with the IPv4 address 10.56.93.203 it can take us a minute. The host range is 10.56.93.201 through 10.56.93.206, the subnet ID is 10.56.93.200, and the broadcast address is 10.56.93.207. Figuring that out in our heads may not be something that we can do accurately. Thankfully, we can rely on subnet calculators or IP Address Management (IPAM) tools to help us do this quickly and with precision.
When it comes to IPv6, people can sometimes be intimidated by the size of the IPv6 addresses. Others may be concerned about having to work with hexadecimal numbers. Even those experienced with IPv6 addressing occasionally fall back into “decimal thinking.” Some may feel that the complexity of dealing with IPv4 subnetting is more well-known than having to delve into learning the new style of IPv6 addressing. Our familiarity with IPv4 leads us toward the tried-and-true IPv4 techniques for handling addresses. Many may feel comfortable with using Microsoft Excel spreadsheets to keep track of addresses, but have to admit that they are not scalable or the best interface for the task. Spreadsheets are not the right answer for maintaining the up-to-32 hex digits separated into eight sections delimited with colons that IPv6 addressing requires.
In many ways, IPv6 prefixes are easier to work with than IPv4 subnets. With IPv6, there are only a few standard prefix lengths that an organization will use. With the vast amount of IPv6 address space, there is “room to breathe.” There is no need to try to assign the smallest necessary address block to a network based on the number of hosts on that network. IPv6 addresses can be laid out in such a way to ease management and operations rather than, in the case of IPv4, trying to conserve the scare addressing resource.
The IPv6 Address Architecture has been set since 2006 (RFC 4291). The common IPv6 addressing convention is to use a /48 as the recommended prefix length for a “site” (RFC 6177), but an ISP might elect to assign a /56, a /60, or a /64 of provider-assigned (PA) IPv6 addresses to a customer. It is recommended that the prefix length always be evenly divisible by four bits and thus fall on the nibble (hex-digit) boundary. When it comes to an access network, a /64 is the predominant prefix length used for all types of links (broadcast, point-to-point, multipoint, tunnel, whatever) (RFC 5375). It is possible to use a /128 if you need a host route for Route Health Injection (RHI), anycast, loopback prefix, etc. One might occasionally want to use a /127 prefix (RFC 6164) for a point-to-point link that only needs two IPv6 addresses. The old RFC 3627 said that using a /127 was harmful (now moved to historic status with RFC 6547), but then RFC 6164 described why this may be necessary to avoid the “ping-pong” issue and/or constrain the neighbor cache table size.
These few standard IPv6 prefix lengths should be used most frequently and network engineers should avoid using odd prefix lengths at all costs. Organizations should not be using a /96 prefix or anything like a /112 (although this was discussed at NANOG48). Your organization should also not use a /126 prefix for any point-to-point links. That is just trying to apply legacy “IPv4 thinking” to IPv6 and should be avoided at all costs. No organizations should be using IPv6 prefix lengths that do not fall on a nibble boundary such as a /57 or /99. Such prefix lengths are highly non-standard and cause too much complexity without any real benefit.
One may consider using a subnet calculator for IPv6 addressing. There are several IPv6 subnet calculators accessible via the Internet. Some use a web interface, some are a downloadable executable, and others are conveniently offered as apps for mobile devices. However, with IPv6 you do not necessarily need to use them because the prefix lengths are pretty standard. A /64 prefix length is going to be the dominant size used for all network types. There is no need to perform any more granular “subnetting” of IPv6 /64 networks. IPv6 networks do not use a subnet number or a broadcast address. Therefore the concept of a subnet calculator is not as applicable to IPv6.
Instead, organizations need a utility for laying out their IPv6 addressing plan rather than using a subnet calculator for segmenting network addresses. There is also a distinction between an IPv6 address planning tool (used for determining your address plan) and an IPv6 address management tool (used for actual deployment of IPv6). You can use an IPv6 IPAM tool when it comes to planning your organization’s addressing hierarchy for sites, laying out your prefixes, but you do not need an IPv6 subnet calculator. A solid IPAM system could actually be more immediately useful helping us keep track of all our tiny IPv4 subnets.
One issue is that there hasn’t been a single resource for IPv6 addressing knowledge. There are articles found on the Internet here and there but not knowing where to find information on IPv6 addressing has made it difficult for organizations to determine the best practices for their IPv6 deployment. IT engineers tend to lack experience creating IPv6 addressing plans so they are unsure of the best way to lay out the IPv6 prefixes. For most organizations, it has been so long since they originally created their IPv4 addressing plan, that they are unsure of how to approach a greenfield IPv6 addressing exercise. The Infoblox IPv6 Center of Excellence (COE) has written many articles on the subject of IPv6 addressing. There is also great book on “IPv6 Address Planning” by Tom Coffeen that you will want to explore.