IP Addressing – IPv4 Addressing

IP version 4 (IPv4) is composed of five address classes, of which the first three classes (A, B, and C) are of great interest. Class D is used in multicast technologies and class E is reserved for experimental use. The most important features of each class are detailed below:

Class	Leading Bits	Size of Network Portion	Size of Host Portion	Number of Networks	Addresses per Network	Start Address	End address
A	0	8 bits (/8)	24	128	16,777,216	0.0.0.0	127.255.255.255
B	10	16 bits (/16)	16	16,384	65,536	128.0.0.0	191.255.255.255
C	110	24 bits (/24)	8	2,097,152	256	192.0.0.0	223.255.255.255
D	1110	–	–	–	–	224.0.0.0	239.255.255.255
E	1111	–	–	–	–	240.0.0.0	225.255.255.255

 

Planning for IPv4 Addressing

The first step in the IPv4 addressing design is estimating the size of the network in order to establish how many IP addresses will be needed, as illustrated in the sample topology in Figure 6.1 below:

Figure 6.1 – Sample Topology

The example above consists of a medium- to large-sized company, with the headquarters location connected to the regional offices via a backbone link. The regional offices further connect to several branch offices and home offices via cable/Frame Relay links. Also used is an ISDN provider as a backup solution for both regional offices.

First, determine how many networks (i.e., locations) will form the overall network. The topology above includes the following:

• One main location
• Two regional locations
• Four branch locations/home offices

Then, take all these sites and determine the overall size of each network, meaning how many devices need to be addressed (e.g., end systems, printers, plotters, router interfaces, switches, servers, firewalls, and other devices). All of these details can be extracted from the network design plan documentation, which is usually provided by the decision-makers within the organization.

Next, figure out the addressing needs for each individual location, including the following:

• Which devices in each location will use static IP addressing (e.g., servers)
• Which devices will use dynamic addressing (through DHCP)
• Which areas will use private addresses
• Which areas will use public addresses and how many of these you will need to get from the ISP
• Which address class will be used
• How many networks will need to be obtained from the public authority (IANA)

Beginning this analysis process with the headquarters location, calculate the number of IP addresses needed for routers, switches, workstations, servers, firewalls, and phones. After calculating the total number of necessary addresses, you should always plan for growth and reserve 20% to 30% of additional addresses for future use.

Repeat this process with each location in the topology and centralize the results in order to have a clear picture of the number of necessary IP addresses, as illustrated below:

 

Location	Router Interfaces	Switches	PCs	Servers	Firewalls	Phones	Total	Total + Growth (20%)
HQ	20	35	650	40	10	650	1405	1686
Regional 1	10	5	200	5	2	200	422	506
Regional 2	10	5	200	5	2	200	422	506
Branch 1	2	1	5	0	0	5	13	15
Branch 2	2	1	5	0	0	5	13	15
Home 1	2	1	2	0	0	0	5	6
Home 2	2	1	2	0	0	0	5	6

 

The result is around 2,740 IP addresses for the entire network topology, including 20% for estimated growth.

As a network designer, once you determine the number of necessary IP addresses, the next big decision is whether private, public, or a combination of private and public addresses will be used. Private internetwork addresses are defined in RFC 1918 and are used internally within the network. From a real-world standpoint, because of the limitation of the number of public IP addresses, Network Address Translation (NAT) techniques are usually used to translate private internal numbers into external public addresses. Internally, you can use one of the following ranges of addresses:

• 10.0.0.0/8 (10.0.0.0  to 10.255.255.255), usually used in large organizations
• 172.16.0.0/12 (172.16.0.0  to 172.31.255.255), usually used in medium organizations
• 192.168.0.0/16 (192.168.0.0  to 192.168.255.255), usually used in small organizations

Any address that falls within the three private address ranges will not be routed on routers on the Internet. These devices have policies and access lists configured to ensure that any packet containing a private address that arrives at an inbound interface will be dropped.

All of the other addresses are public addresses that are allocated to ISPs or other point-of-presence nodes on the Internet. ISPs can then assign Class A, B, or C addresses to customers so they can use them on devices that are exposed to the Internet, such as the following:

• Web servers
• DNS servers
• FTP servers
• Other servers that run public-accessible services

Deciding on which type of addresses to use will result in one of the following types of connections:

• No Internet connectivity
• Only one public address (or a few) for user Web access
• Web access for users and public-accessible servers
• Every end system has a public IP address

Referring back to Figure 6.1, no Internet connectivity would imply that all the connections between the locations are private links, and the enterprise is not connected to the Internet in any of its nodes. In this case, you do not need any public IP addresses because the entire address scheme can be from the private address ranges.

Another situation would be the one in which you have Internet connectivity from all network locations but you do not have any servers that run public-accessible services (e.g., Web, FTP, or others). In this case, you would need a public IP address that allows users to receive Web access. NAT can be used to translate traffic from the internal network to the outside network, so the internal networks contain only private IP addresses and the external link can use just one public address.

The third scenario is one of the most common, especially when considering the growth of enterprise networking. This involves having user Internet connectivity (as in the previous scenario) but also having public-accessible servers. Public IP addresses must be used to connect to the Internet and get to the specific servers (e.g., Web, FTP, DNS, and others). The internal network should use private IP addresses and NAT to translate them into public addresses.

The most highly unlikely scenario would be the one in which every end system uses public-accessible servers from the global Internet. This is a dangerous situation because the entire network is exposed to Internet access, and this implies high security risks. In order to mitigate these risks, you must implement strong firewall protection policies in every location. In addition to the security issues, this scenario is also not very effective because many IP addresses are wasted, and this is very costly. All of these factors make this a scenario not to be used in modern networks.

The two most common solutions from the scenarios presented above are as follows:

• One or a few public addresses for user Web access
• A few public addresses that provide Web access for users and public-accessible servers

Both scenarios would employ private internal addressing and NAT to reach outside networks.

For a deeper analysis of the previously mentioned aspects, refer to Figure 6.2 below, which focuses on how they map to the Cisco enterprise architecture model, and where private and public addressing should be used.

Figure 6.2 – Cisco Enterprise Architecture Model Addressing

First, assume that you have some kind of Internet presence in your enterprise that may offer services either to internal users in the Access Layer block or to different public-accessible servers (e.g., Web, FTP, or others) in the enterprise edge module.

Regardless of what modules and components receive Internet access, you will run NAT at the edge distribution submodule. This submodule will have a multilayer switch that provides NAT services in order to translate between the internal addressing structure used on the enterprise campus module and external public IP addressing. You can also use NAT mechanisms in the enterprise edge module.

Using the 10.0.0.0/8 range internally, both in the enterprise campus module and in the network management submodule, enterprise campus module devices that use private IP addressing will include the following components:

• Access Layer block
• Distribution Layer block
• Core Layer block
• Server farm block

The edge distribution submodule will use a combination of private and public IP addressing. The enterprise edge module will also use a combination of private and public addressing, depending on each component. The remote access block can use a combination of private and public addressing and will need to support some kind of NAT techniques. The WAN block can use either private addressing (when connected to other remote sites) or public addressing (when connected to outside locations for a backup solution).

 

 

Hierarchical Network Addressing

Hierarchical design involves the address summarization techniques described previously. After planning IPv4 addressing and determining the number and type of necessary addresses, you should investigate whether hierarchical design is necessary. Hierarchical design is useful when you need to build a large enterprise-scalable solution.

If you decide to implement the hierarchical network addressing scheme, the next step is ensuring you understand the math behind it and how route summarization works. Below is an example of combining a group of Class C addresses into an aggregate address. Summarization is a way in which you can represent several networks in a single summarized route. In a real-world scenario, you can use a subnet calculator to generate the most appropriate aggregate route automatically from a group of addresses.

In the example below, the campus backbone component connects several other buildings. In a single building, there are several networks in use, such as the following:

• A network for the server farm
• A network for the network management area
• A few networks for the Access Layer (that serves several departments)

Take all of these networks and aggregate them into one single address that can be stored at the edge distribution submodule or at the core of the network. The first thing to understand when implementing a hierarchical addressing structure is that you need to use continuous blocks of IP addresses. In this example, 192.100.168.0 through 192.100.175.0 is used.

 

 

In this scenario, summarization is based on a location where all of the uppermost bits are identical. Looking at the first address, the first 8 bits equal the decimal 192, the next 8 bits equal the decimal 100, and the last 8 bits represent 0. The only octet that changes is the third one; more specifically, only the last 3 bits in that octet change when going through the address range.

The summarization process involves writing the third octet in binary format and then looking for the common bits on the left side. In the example above, all the bits are identical up to the last 3 bits in the third octet, so there are 21 identical bits and all the addresses will be summarized to 192.100.168.0/21.

Once you decide to use a hierarchical addressing design and understand the math involved in this process, you should approach this with a modular and scalable design, and decide how you will break up the organization, thinking about the number of network modules, campus components, and remote locations, in terms of addressing. This includes decisions regarding applying a hierarchical address model to each module or to the entire enterprise.

Another aspect to consider is the way summarization may affect the routing protocols used. Summarization usually affects routing because it reduces the size of the routing tables, the processor, and memory utilization, but it offers a much faster convergence of the routed network. You also should decide on the number of nodes (including end-user stations) available per summarization group. The most important advantages of using route aggregation are as follows:

• Lower overhead
• Improved network stability
• Eases future growth

Figure 6.3 below is an example of an enterprise using a campus with multiple buildings:

Figure 6.3 – Enterprise Campus with Multiple Buildings Addressing

For internal private addressing, you should use the popular 10.0.0.0/8 range. Within the organization domain, aggregate two separate building infrastructures (on the same campus or for remote buildings) using the 10.128.0.0/16 and 10.129.0.0/16 ranges.

Note:    You should use 10.128.0.0 and 10.129.0.0 instead of 10.1.0.0 or other lower second octet because many organizations already use those lower-range octets, and you would have problems if the company decided to buy another company that uses one of those ranges. This minimizes the chance of overlap when merging other infrastructures within the network.

Going deeper within each building, you can break down the addressing scheme within different departments using the 10.128.1.0, 10.128.2.0, or 10.129.1.0, 10.129.2.0 networks with a 24-bit mask. Because of the scalable design, you could include another tier above the departmental addresses that would be addresses within the 10.129.0.0/21 range, for example.

When moving beyond that point, you will go into the enterprise edge module that contains various blocks (e.g., E-commerce or Internet connectivity) that have point-to-point connections to different ISPs and use Variable Length Subnet Masking (VLSM) to break it down.

In summary, from a network design standpoint, it is very important to tie the addressing scheme to the modular enterprise network design.

The advantages of using route summarization and aggregation are numerous, but the most important advantages are as follows:

• Isolates changes to the topology to a particular module
• Isolates routing updates to a particular module
• Fewer updates need to be sent up the hierarchy (preventing all the updates from going through the entire network infrastructure)
• Lower overall re-calculation of entire network when links fail (i.e., a change in a routing table does not converge to the entire network); for example, route flapping in a particular department is constrained within the specific department and does not have a cascading effect on other modules (considering the example above)
• Narrow scope of route advertisement propagation
• Lowers frequency of routing updates (routing protocol metrics and timers can be modified)
• Summarized module is easier to troubleshoot
• Prevents routing loops and black holes

 

Address Allocation Techniques

An important question in the IP addressing design is how will the addresses be assigned? One way would be to use static assigning and the other way would be to use dynamic protocols such as Dynamic Host Configuration Protocol (DHCP). When deciding upon the address allocation method, you must answer the following questions:

• How many end systems do you have?

If you have a small number of hosts (less than 50), you can consider using statically assigned addresses, but if you have several hundred systems, you need to use DHCP to speed up the process.

 

• What does the security policy demand?

Some organizations demand the use of static IP addressing for every host or for every node in order to create a more secure environment. For example, an outsider cannot plug in a station to the network, automatically get an IP address, and have access to internal resources. The organization’s security policy might demand static addressing regardless of the network size.

 

• What is the likelihood of renumbering?

This includes the possibility of acquisitions and mergers in the near future. If the likelihood of renumbering is high, DHCP should be used.

 

• Do you have high availability demands?

If the organization has high availability demands, DHCP should be used in a redundant server architecture.

In addition, static addressing should always be used on certain devices in certain modules, such as the following:

• Corporate servers
• Network management workstations
• Standalone servers in the Access Layer block
• Printers and other peripheral devices in the Access Layer block
• Public-accessible servers in the enterprise edge module
• Remote devices in the Access Layer block
• WAN devices