Taking the time to come up with a great plan before implementing anything on your network is a great idea, but your IP address scheme is especially important. It's all too easy to accept defaults and get everyone up and running quickly. For some small companies, the default IP address layout that ships with your router (or whichever device handles DHCP by default) may suffice. But further down the road, it needs to change as companies grow. Being prepared for potential growth is critical. Implementing an IP address scheme is easy, but changing this scheme on a network that's already been rolled out is a great challenge. Always take the time to plan accordingly.

The first consideration for determining your IP address scheme is what types of machines you'll need to provide addresses to. Often, you'll have servers, workstations, and printers to deal with. But nowadays, we also have other devices on our network such as IP phones, company-issued phones, conference systems, tablets, and more. When you start to add all these devices together, a typical 24-bit network with 254 usable addresses doesn't seem to be all that large, even for a small company. Worse, some devices (such as laptops) have multiple network interface cards. If you put all that together, you'll find that those 254 addresses can get used up really quickly.

Having multiple subnets would certainly help. With subnetting, you can create individual networks for each type of service, each with their own set of IP addresses. You can, for example, have your servers on one subnet, printers on another, and end-user workstations on their own. Instead of having to split a single 24-bit subnet between these three types of devices, you can spread them out over several networks. We will cover subnetting in more detail in Chapter 8, Understanding Advanced Networking Concepts, but for now segregating your network is almost always a good idea, for reasons even beyond IP addressing.

Another factor to take into consideration is limiting your broadcast domain. A single 24-bit network (which is often the default on network devices out of the box) is a single broadcast domain. In a nutshell, one device can talk to another device on your network without being routed first and share the same broadcast domain. If you only have a few devices, this doesn't really matter (unless one device handles a ridiculously large amount of traffic). But in most networks, breaking up your broadcast domain enhances performance. If you have a router separating your subnets, you are effectively breaking up your broadcast domain. Thus, it would be more difficult for a single node to saturate your network if it is on its own subnet. However, no solution is perfect and individual broadcast domains can become saturated.

One useful tool that you can use when planning your IP scheme is the ipcalc utility. The ipcalc utility can help you understand how many IP addresses you will be able to have available with each scheme. This utility is available via apt-get in Debian, and it doesn't need any extra repositories. While there is an ipcalc command built into CentOS, it's not the same thing and it's not useful. If possible, I would stick to the Debian version. To use it, simply execute ipcalc along with a network you are thinking about using. For example, you could run the following as a test:

ipcalc 10.10.96.0/22

ipcalc showing subnet information for a 10.10.9.60/22 internal network

In the previous example, we can see that if we chose a 10.10.96.0/22 scheme, we would have 1022 allowable IP addresses, a subnet mask of 255.255.252.0 and this would be a class A private network. While you'll learn more about subnetting later in this book, the ipcalc utility will be handy for you to play around with and determine how specific IP layouts would look.

Another topic that's worth bringing up in IP addressing is IPv4 versus IPv6. For quite a long time, IPv4 has been sufficient for everyone's needs. Unfortunately, the time has come where IPv4 addresses on the public Internet are starting to run out (and in many situations, already has). The benefit of IPv6 is that there are so many IP addresses available; it's completely inconceivable that we would ever run out again. There is also a security benefit to IPv6, since the address space is so large that targets are abstracted (in essence, security through obscurity).

With this in mind, you might be tempted to roll-out IPv6 addresses over IPv4 within your network. However, my suggestion is unless you have a very good reason to do so, don't bother. The depletion of IPv4 addresses only affects the public Internet, not your internal network. While you can certainly roll-out IPv6 internally, there's no benefit to doing so. Given that IPv4 has over 4 billion addresses available, you would need quite a few devices in order to justify IPv6. On the other hand, IPv6 is certainly useful (and will eventually be required) for telecoms. It's also useful for those of you who are studying Cisco exams, as understanding of this topic is required. But for the purposes of this book and setting up Linux networks, IPv6 doesn't justify the administration overhead.

In summary, it's important to plan ahead. IPv4 is good enough for our needs and splitting our network into subnets is a good idea (even if you think your network will never surpass 254 addresses). Plan big; even in the worst-case scenario, you may never use all the IP addresses you configured. But even if you don't plan on using a large number of IP addresses, having them available in case you wish to grow your network is a good idea and much easier to implement later. In my experience, I've actually had the task of reconfiguring a company network that wasn't designed for growth. While it was definitely a learning experience, it wasn't an enjoyable one.