Network Protocols

In Chapters 1 through 3 we mainly concentrated on Physical and Data Link layer technologies, protocols, and specifications. These characteristics of LANs (and WANs) are absolutely essential to understand. However, as we move closer to the world of routers and routing, we have to start looking at the protocols that ride on top of these technologies. While a variety of network protocols exist for the purpose of moving data across an internetwork, three in particular make up the bulk of the implementations that you’ll come across. These include TCP/IP, IPX/SPX, and AppleTalk.

The first important thing to understand is that none of these protocols define a single entity. Instead, each represents what is known as a protocol suite. A protocol suite is actually a group of protocols that work together (at different layers) to make network communication possible. If you recall from Chapter 1, most network protocol suites do not map to the OSI model directly, but include protocols that can generally be mapped to defined OSI layers. Some suites (such as AppleTalk) map to the OSI model more clearly than others. In this chapter we’ll not only look at the protocols that make up the TCP/IP, IPX/SPX, and AppleTalk suites, but also relate these protocols to the layers of the OSI model.

The material to be covered in this chapter includes:

  • Transmission Control Protocol / Internet Protocol (TCP/IP)
  • Internetwork Packet Exchange / Sequenced Packet Exchange (IPX/SPX)

The 4-Layer TCP/IP Network Model

The Department of Defence TCP/IP model is a 4-layer model that defines areas of responsibility much like the OSI, while providing insight into the functions of the different protocols that make up the TCP/IP suite. The model provides an excellent point of reference when compared to the OSI. We won’t look at all the details of the TCP/IP model just yet – the majority will be covered in Chapter 4. My feeling is that the data encapsulation process is much better explained using a popular protocol suite.

To begin, let’s take a look at how the TCP/IP model maps to the OSI model. While the names of the TCP/IP layers are different, they generally encompass the same responsibilities as one or more OSI layers. Consider the diagram below.

Figure: Comparing the OSI and TCP/IP network models.

Tip: Although the layers of the TCP/IP model technically use different names, Cisco will still refer to protocols by their associated OSI layer name. For example, Cisco will describe TCP as being a Transport layer protocol.

For the sake of illustration, I’ve included some of the key protocols that make up the TCP/IP suite in the figure below. Be aware that the terms data, segment, packet, and frame still apply as data is encapsulated in the TCP/IP model.

Figure: TCP/IP protocol stack including common protocols and network technologies.

Defining Valid IP Address Ranges for Subnets

Once you’ve managed to define a custom subnet mask that meets your requirements, the next step is calculating the ranges of IP addresses that are valid for a given subnet. Remember that after a custom subnet mask is defined, you have actually turned one big network address space into a number of smaller sub-network address spaces. Because of this, certain addresses will no longer be considered local to one another.

Calculating ranges of addresses isn’t difficult, but we’ll again need to go back to binary to understand how this is accomplished.

Consider the example of network 192.168.0.0 with a custom subnet mask of 255.255.248.0. Remember that this is one of the private address ranges outlined in RFC 1918, and the default mask is 255.255.0.0 in this case. To begin, we’ll need to convert the subnet mask to binary, and define the network, subnet, and host portions, as shown in the figure below.

Figure: Network, subnet and host portions based on the custom subnet mask 255.255.248.0.

Notice that the first 16 bits represent the network, the next 5 define subnets, and the last 11 are used to uniquely identify hosts on a subnet.

Since 5 bits are used to define the subnet portion of the address, this gives us 25-2 or 30 possible subnets. Each subnet can support 211-2, or 1022 unique hosts. Calculating the range of available addresses for each subnet involves beginning with the first subnet that is not all binary 0s, and then looking at the additional subnets. In this case, the first subnet is defined as the one where all but the last bit is set to binary 0. The first host on the 00001 subnet will be the lowest host value that is not all 0s, since the all 0s address identifies the subnet. The highest address in a range will be the highest host value that is not all 1s, since that value is reserved for broadcasts. I know this can be a little confusing, so take a look at the example in the figure below.

Figure: Defining the IP address range for the first subnet.

If you take the addresses in the figure above and convert them back to decimal, you’ll see that the range of IP addresses available on the first subnet are those from 192.168.8.1 up to 192.168.15.254.

Calculating the next range of addresses requires that we change the subnet ID to its next lowest value. In this case, it would be 00010. To make things easier, consider this to be an isolated 5-bit binary number. The first subnet is 1; the next is 2, then 3, then 4, and so forth. In this way, the first five subnet IDs in our example would be those listed in the table below.

Subnet ID Decimal Value 00001 1 00010 2 00011 3 00100 4 00101 5

Notice that each subnet simply increases by a value of 1 when we consider it as an isolated 5-bit number. This would continue all the way up to 11110, at which point we run out of subnets. Remember that according to Cisco, the subnet IDs of all binary 0s and all binary 1s should be avoided.

Our example continues by calculating the ranges for the second and third subnets. Notice in the figure below that the subnet ID has changed for each, but that we still always include the lowest and highest possible host values – the beginning and end of each range.

Figure: Defining the IP address ranges for the second and third subnets.

The table below outlines the first three address ranges, along with the subnet ID (when the host bits are all set to binary 0) and the broadcast address for that subnet (where the host ID is set to all binary 1).

Subnet ID Address Range Broadcast Address 192.168.8.0 192.168.8.1 – 192.168.15.254 192.168.15.255 192.168.16.0 192.168.16.1 – 192.168.23.254 192.168.23.255 192.168.24.0 192.168.24.1 – 192.168.31.254 192.168.31.255

If you look closely, you should notice a pattern developing – each new subnet (in this example) starts at a multiple of 8 in the third octet, and each ends just before the next multiple of 8. In this case, the fourth subnet would begin at the next multiple of 8, 192.168.32.1 and go up to just before the next multiple of 8 in the third octet. Since the next multiple of 8 is 40 (and represents the beginning of the next subnet), it must end at 39, or 192.168.39.254.

The pattern with multiples of 8 only occurs with a 248 custom mask value. With different masks, different multiples will become clear.

Let’s try another example. We’ll use the address 10.0.0.0 with a subnet mask of 255.255.0.0. With this example, there are 8 bits used for subnetting, leaving 16 bits for hosts. The figure below outlines the first three ranges of addresses in this example, beginning with the first subnet – 00000001 in the second octet.

Figure: First three address ranges for the address 10.0.0.0 using the custom mask 255.255.0.0.

In this case, the ranges move in multiples of 1 in the second octet – the first subnet is 1, the second is 2, the third is 3, and so forth. It would be safe to say that the fourth subnet will be the range between 10.4.0.1 – 10.4.255.254. Once you’ve found the multiple, determining the ranges is much easier. The first three subnet IDs, address ranges, and the broadcast address on each subnet are shown in the table below.

Subnet ID Address Range Broadcast Address 10.1.0.0 10.1.0.1 – 10.1.255.254 10.1.255.255 10.2.0.0 10.2.0.1 – 10.2.255.254 10.2.255.255 10.3.0.0 10.3.0.1 – 10.3.255.254 10.3.255.255

Some people find Class C address ranges a little trickier to deal with, but if you follow the rules, they are no more difficult that any other range. For example, let’s say that we have the network address 202.191.15.0 with a subnet mask of 255.255.255.240. We know that subnetting occurs in the fourth octet in this example, and that we have 4 subnet bits and 4 host bits. The first subnet will again be lowest non-zero value, or 0001. The first host in each range will be the first non-zero value, and the last host the highest value that is not all binary 1s. The figure below outlines the first 3 ranges in this case.

Figure: First three address ranges for the address 202.191.15.0 using the custom mask 255.255.255.240.

Notice that the values in the ranges look a little different when converted to decimal, as illustrated in the figure above. This is because the subnet IDs end in non-zero values.

Subnet ID Address Range Broadcast Address 202.191.15.16 202.191.15.17 – 202.191.15.30 202.191.15.31 202.191.15.32 202.191.15.33 – 202.191.15.46 202.191.15.47 202.191.15.48 202.191.15.49 – 202.191.15.62 202.191.15.63

If you’re confused by this example, it’s probably because of the oddities that seem to occur in the ranges. For example, why is 202.191.15.16 not a valid IP address when a subnet mask of 255.255.255.240 is used? Look again at what happens when you convert this address to binary – the host portion is all binary 0s, which we already know is not allowed! The key to understanding address ranges is always the same – when in doubt, break everything down into binary. Looking at addresses in decimal only will often make things much more confusing than they need to be.

IPv6 Deployment Strategies: Translation Techniques

Similar to many of the solutions proposed to extend the life of the IPv4 address space, a variety of proposal exist for the purpose of translating IPv6 to IPv4 addresses as a method of migrating networks to IPv6. The common thread with these solutions is that rather than use the dual-stack or tunneling techniques outlined earlier, a company would instead run IPv6 internally on its network, and then use some type of translation server or gateway for continued access to the IPv4 Internet.

Although this method would break the “end-to-end” connectivity that is a central premise of IPv6, it does present an interesting solution that many companies may choose to employ as a migration strategy. One such recommendation is outlined in RFC 2766 is known as Network Address Translation – Protocol Translation (NAT-PT). A variety of IPv6 translation RFCs are currently under consideration, but the ultimate standards are still largely yet to be determined.

IPv6 Deployment Strategies: Tunneling Techniques

A variety of different tunneling techniques already exist for the purpose of interconnecting IPv6 networks using the infrastructure provided by existing IPv4 networks. For example, imagine if a company were to deploy IPv6 in two of their offices. Using various tunneling methods, the company could interconnect these offices over an IPv4-based network such as an existing WAN connection or the Internet. In order to do this, the routers providing the interconnection between the IPv6 and IPv4 networks must be dual stack devices. The advantages of using tunneling include the fact that it allows service providers to begin providing end-to-end IPv6 connections, even before they have fully converted their infrastructure to supporting IPv6.

A number of different methods for tunneling IPv6 over IPv4 networks are currently in use including manually configured tunnels, generic routing encapsulation (GRE) tunnels, automatic IPv6 to IPv4 tunnels that use techniques similar to IPv4-mapped IPv6 addresses, and more. One inherent limitation of IPv6 tunneling techniques is that they do not support common Internet connection methods like network address translation (NAT).

IPv6 Deployment Strategies: Dual Stack Technique

The dual stack technique is likely to become quite common as companies make the transition from IPv4 to IPv6. As the name suggests, this method involves running both IPv4 and IPv6 protocol stacks on network equipment such as hosts and routers until the transition to a purely IPv6 network can be completed. Under this scenario, Cisco routers on a network would be configured to route both IPv4 and IPv6 traffic, with hosts configured to use both protocol stacks as well. Cisco has already developed versions of its IOS software that support both protocol stacks simultaneously. Unfortunately, it will likely take quite some time before all of the applications that end users require access to support IPv6. As such, using a dual-stack technique would quite likely be a long-term arrangement, requiring two protocol stacks to be managed simultaneously, not to mention greater memory requirements on equipment like routers. However, the dual stack technique does provide an effective method for organizations to begin deploying and testing IPv6 throughout their networks.

Private IP Addresses

Based on the incredible growth of the Internet, it soon became evident that the IP address space would quickly become exhausted if the growth continued. To account for this, the IETF looked for ways in which the address space currently available could be extended. A future solution exists in the form of IP version 6 (or IPv6 for short), which uses a much larger 128-bit addressing scheme. In order to deal with the issue in the shorter term, it was decided that certain address ranges would be deemed “private”. Private IP address ranges are defined in RFC 1918.

The idea behind private ranges of IP addresses is surprisingly simple – certain IP address ranges would be dedicated and limited to use for hosts on private networks. These addresses would no longer be considered valid (or be routable) on the public Internet. Instead, companies could allocate addresses in these ranges as they saw fit, with the address ranges open and available to everyone. Private IP addresses are a practical solution, since companies can use technologies such as Network Address Translation (NAT) or Proxy servers to connect their private networks to the public Internet. When these technologies are used, a single public IP address can be used to connect an entire organization to the Internet. NAT will be looked at in detail later in the series. For the time being, the figure below shows a network that connects to the Internet using only a single public IP address.

Figure: Network using NAT to connect to the Internet.

To the outside world (the public Internet), all requests from within the company above appear to be coming from the single public IP address.

Three ranges of private IP addresses are defined in RFC 1918. The ranges defined have been allocated custom subnet masks that define their network and host portions. The lists below outline the private IP address ranges defined in RFC 1918.

Network Address: 10.0.0.0 Subnet Mask: 255.0.0.0 Range of Addresses: 10.0.0.1 – 10.255.255.254

Network Address: 172.16.0.0 Subnet Mask: 255.240.0.0 Range of Addresses: 172.16.0.1 – 172.31.255.254

Network Address: 192.168.0.0 Subnet Mask: 255.255.0.0 Range of Addresses: 192.168.0.1 – 192.168.255.254

Notice the second private network address, 172.16.0.0 with a subnet mask of 255.240.0.0. It’s easy to immediately react and consider this to be a Class B address, based on the fact that the first octet value falls into the 128-191 range that we learned earlier. Instead, the private portion of this address range only goes as high as 172.31.255.254. Addresses beginning with network 172.32.0.0 are actually valid, public IP addresses. The 192.168.0.0 network uses a special subnet mask as well. In this case, its mask appears to be that of a Class B address. For the time being noting the differences is enough – we’ll explore how custom masks are defined shortly.

So why would a company want to use private IP addresses? A big reason is because they offer a great degree of flexibility. A company can now pick one of these network IDs, and address internal hosts as they see fit. In the past, public IP addresses were allocated to companies, and later needed to be “rented” from ISPs. When private IP addressing is used, a company’s need for public addresses is dramatically reduced, sometimes to only one or just a few IP addresses.

So which private range should a company use? Well, that’s entirely up to them. Obviously the 10.0.0.0 network ID offers the greatest flexibility, based on the number of possible host addresses it provides. For small networks, the 192.168.0.0 range is probably most appropriate. At the end of the day, however, it’s completely in the hands of the network administrator.

Tip: For a more detailed look at the private IP addressing ranges, see RFC 1918.

Classful IP Addressing

Since there are literally millions of IP addresses available, the IETF originally designated what are known as classes of IP addresses. The purpose of these classes was to break up the IP address space into ranges that accounted for networks of different sizes. The term “classful” is used to describe addresses that are looked at according to their class. In reality, the world of IP addressing has changed such that classes of addresses are much less important than they used to be – later in the chapter, we’ll take a look at classless addressing, including how and why it came about.

You’ll definitely need to be familiar with classful addressing, since it forms the basis upon which IP addresses were originally defined, and is still a factor with routing protocols such as RIP version 1 and IGRP. Five different classes of addresses exist, and are distinguished according to the values found in their first octet. The table below outlines each of the five ranges.

Class First Octet Decimal Value Network and Host Portions Hosts Supported Per Network Details
A 0-126 N.H.H.H 16,777,214 Intended for the largest networks only
B 128-191 N.N.H.H 65,534 Intended for medium sized organizations
C 192-223 N.N.N.H 254 Intended for small organizations
D 224-239 N/A N/A Reserved range used for multicasting
E 240+ N/A N/A Experimental range

The value of the first octet of an IP address holds the immediate answer to the class an address falls into. Notice that Class A addresses always begin with a value between 0 and 126. As such, the address 64.12.203.1 can safely be identified as Class A. From the table above, you should also note that in a Class A address, the first octet uniquely identifies the network (designated by the “N”), while the last three octets uniquely identify a host (designated by the “H”) on that network. Only Class A, B, and C addresses are valid to assign to hosts. Class D addresses are used to support multicasting, while Class E addresses are reserved for experimental use.

You may have noticed that the first octet value of 127 is missing from the table above. What is the reason for this? The 127 range is actually reserved for diagnostic functions – for example, the address 127.0.0.1 is the loopback address. Ping that address, and you’re actually testing the TCP/IP connectivity of the source machine.

IP Addressing Basics

Back in Chapter 4, we took a very basic and introductory look at the concept of an IP address. Recall that IP addresses are logical addresses made up of two parts – the first part represents a network, and the other, a unique host on that network. Before we get into the details of IP addressing, you’ll first need to know a little more about how binary and decimal numbers relate to each other.

Binary-Decimal Conversions

Remember that IP addresses are 32-bits in length, but are usually represented in dotted-decimal notation. As such, the address 192.168.2.200 can also be represented as:

11000000 10101000 00000010 11001000

But why should you care about the binary version? The answer is absolutely critical – in order to truly understand how IP addressing works, you must always take a look at elements such as addresses and subnet masks in binary form. After you’ve had lots of practice in binary, you’ll get very good at “understanding” the numbers when you see them in decimal. Just remember that when starting off, it is important that you convert addresses to binary – doing so will ultimately unlock the secrets of subnetting, determining if hosts are on the same or different networks, and whether IP addresses are valid.

Having said that, our first logical step is learning how to do decimal-to-binary conversions and vice versa. Recall that a 32-bit address is actually grouped into four octets in its decimal form – each octet represents 8 bits in binary. The figure below outlines the decimal and binary values for each of the 8 bits.

DECIMAL 128 64 32 16 8 4 2 1
BINARY 1 1 1 1 1 1 1 1

Notice that each of the eight binary digits has a single decimal value associated with it. An important pattern should be clear in the decimal row – moving from right to left, the value doubles in each successive column.

This is part of what make binary numbering so useful – for any given decimal number, there is one (and only one), way to represent it in binary. After a few examples, understanding how binary numbering works will be clear.

We’ll start with converting binary to decimal, since this is the easiest way to illustrate the conversion process. Imagine you wanted to convert the binary number 01010101 to decimal. Using Table 5-1, you’ll notice that each binary “1” value corresponds to the decimal value above it. If we add together the decimal values that correspond to the 1s in the binary number, we’ll have completed the conversion process. For example, the decimal value of the binary number 01010101 would be:

0 + 64 + 0 + 16 + 0 + 4 + 1 = 85

All I did was take the decimal value of each of the 1s in the binary number and replace them with their corresponding decimal value. In cases where the binary digit was 0, I did not add that value. Consider another example, the binary number 11100011. In this case, the corresponding decimal value would be calculated as:

128 + 64 + 32 + 0 + 0 + 0 + 2 + 1 = 227

I’ve left the 0 decimal values in my examples to act as placeholders – you should consider doing this until you feel comfortable that you remember the decimal values associated with each binary digit.

IP Addressing and Subnetting

For some reason, nothing seems to scare people preparing for the CCNA or CCDA quite as much as subnetting. While I’m not quite sure why this fear exists, I can tell you one thing for certain – subnetting isn’t very difficult at all, as long as you can remember a few simple rules. If you follow along closely, by the end of this chapter you too will realize how easy subnetting can be.

While subnetting is certainly important, there are many IP addressing concepts that you’ll need to understand in order to be successful in passing your CCNA and CCDA exams. Topics that we’ll cover in this chapter include:

  • Binary-decimal conversions
  • Determining classes of addresses
  • Private IP address ranges
  • Defining custom subnet masks and address ranges
  • Classless addressing
  • Classless Inter-Domain Routing (CIDR)

In your new life as a network engineer, these concepts will represent the foundation of your knowledge. Take the time to truly understand them, as you will ultimately use them again and again.