Internet Control Message Protocol (ICMP)

ICMP is yet another protocol at the Internet layer. Internet Control Message Protocol is used as an error reporting protocol in the TCP/IP suite. It is important to begin by noting that ICMP does nothing to make IP reliable. Instead, it simply reports on error situations that exist or occur. ICMP only sends error messages back to the originating host, and not intermediary devices. A good example of a type of error message sent by ICMP is a Source Quench message. These are used when a router receives more data than it can handle. Once its buffers finally fill, the router will send the source host a Source Quench message, effectively letting the source know that it should send data at reduced rate. Note that the message doesn’t include any information on packets that may have been lost. Instead, it simply makes the sender aware that a situation exists. It is still the responsibility of upper-layer protocols to ensure that data arrives at its destination.

You are probably more familiar with ICMP than you realize. Have you ever used the ping utility? If so, what you’ve actually done is sent out ICMP echo messages, and if the address that you attempted to ping was reachable, you received back ICMP echo replies. Ping is an example of a simple ICMP utility that provides information on whether or not hosts can be reached. If the host you’re attempting to ping can’t be reached, you’ll receive an ICMP Destination Unreachable message. ICMP is also used to send messages that notify the sender that the Time to Live (TTL) on a packet has expired.

Consider the example below, which shows a capture of an ICMP echo reply. Note that only the ICMP portion of the frame is expanded.

Ethernet II
Internet Protocol, Src Addr: (, Dst Addr: (
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0x3b5c (correct)
Identifier: 0x0200
Sequence number: 18:00
Data (32 bytes)

Remember that ICMP is simply a reporting protocol – it does nothing to actually remedy any errors that occur.

Tip: For more information on Internet Control Message Protocol, see RFC 792

Address Resolution Protocol (ARP)

ARP is another protocol found at the Internet layer of the TCP/IP model. As the name suggests, ARP is a protocol used to resolve addresses – in this case, finding the MAC address that corresponds to an IP address. Remember that data is encapsulated before being sent over the network. Even though a system may know the IP address it wants to ultimately send data to, it may not know the MAC address. On an Ethernet LAN, systems communicate directly using CSMA/CD, and as such must know the MAC address of the system that data must be sent to next.

Recall that MAC addresses are fixed. IP addresses, on the other hand, are not. Systems can be manually configured with an IP address, or they can obtain one using the Dynamic Host Configuration Protocol (DHCP). As such, it doesn’t make much sense to have a static mapping between the two, since IP addresses may change. Instead, when a system needs to obtain the MAC address associated with an IP address, it sends out a broadcast message asking that the system with the specified IP address reply with its MAC address. Once it receives a reply, the answer is cached for a limited period of time (typically between 2 and 20 minutes) in the system’s ARP table. Caching helps to ensure that ARP broadcasts don’t get out of hand and overwhelm the network.

Since an ARP request is a broadcast, it will be seen by every system in the same broadcast domain. When a system comes across an ARP request, it will check to see if it is the intended recipient. If it is, the system will process the frame. If not, the frame is ignored.

When a system wishes to communicate with another system in a different broadcast domain, recall that the packets must be sent to a router. In this case, the ARP request isn’t looking for the MAC address of the destination host (since the broadcast would never reach it), but instead the MAC address of the router interface to which the frame must first be forwarded.

Internet Protocol (IP)

IP is a connectionless protocol. As such, it doesn’t request acknowledgements for data sent. Instead, it relies on upper-layer protocols (like TCP) to handle reliability functions. IP addresses are probably something that you’re already familiar with. More likely than not, you’ve assigned an IP address to a computer for the purpose of connecting it to the Internet, your office, or something similar. An IP address is most often displayed in what is referred to as dotted-decimal notation, for example IP addresses are made up of two main parts – the first uniquely identifies a network, and the second uniquely identifies a host on that network. Think of this as being similar to a street address. Your house (the host) has a unique address on your road (the network).

You may also be familiar with the fact that IP uses 32-bit addresses. But what does this mean? Simple, computers do just about everything in binary, representing information as a series of 0’s and 1’s. Since an IP address is 32 bits long, it can also be represented as a series of 32 1’s and 0’s. For example, the IP address can also be represented as:

11000000 10101000 00000000 00000001

Don’t worry just yet about how those numbers are generated. By the time you get through Chapter 5, I promise it will seem like the easiest thing in the world.

You’re probably also familiar with something called a subnet mask. The purpose of a subnet mask is to define which portion of an IP address represents the network, and which portion represents the host. For example, if I have an IP address of and a subnet mask of, it means that the first eight bits (referred to as the first octet) represent the network, while the last 24 bits represent a host. In this case, the network ID is 10, while the Host ID is 1.1.1. In Chapter 5 we’ll delve much further into how masks work and how they’re created. For now, it’s important that you simply understand that every IP address requires a subnet mask to be able to distinguish between the network and host portions.

Every IP network requires a unique network ID, and each host on a network requires a unique host ID. That should be simple enough for now – an IP address simply gives us information as to the network on which a unique host can be found.

In order to communicate with a host on a different network, communication requires the use of routing. IP is what is referred to as a routed or routable protocol. That simply means that if a network is configured correctly, a host on one network will be able to communicate with a host on another, with routers acting as intermediaries deciding where a packet should be sent next. We’ll take a look at routing protocols in detail in Chapter 8.

TCP/IP and the OSI Model – The Network (Internet) Layer

If you recall, the Internet layer’s primary responsibilities are determining a path between networks (routing), as well as network addressing. The addressing that takes place at the Internet layer is often referred to as logical addressing. These addresses aren’t “burned-in” like Ethernet MAC addresses, but instead are assigned by an administrator. The addressing protocol of the TCP/IP stack is the Internet Protocol (IP).

Note that TCP/IP routing protocols such as RIP, OSPF, and others also exist at the Internet layer. These will be looked at in Chapter 8, when routing is covered in detail.


The Transmission Control Protocol/Internet Protocol is by far the most popular protocol suite in use today, thanks to the growth of the Internet. TCP/IP has changed a great deal over the years, as different protocols were created or adapted to address different needs. For example, TCP was originally developed back in 1974, while TCP and IP came together in 1978. It wasn’t until January 1st, 1983 that all systems on the Internet (then known as the ARPANET) officially had to use TCP/IP. The groups who set the direction for the Internet (and decide what will become a standard) are the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG).

Before we go any further, you should be aware of what are known as Requests For Comments (RFCs). Before anything becomes an Internet standard, it has to go through the RFC process. While all Internet standards are defined in RFCs, not all RFCs become standards. If you take the time to read RFC 1149 or 1438, you’ll understand what I mean. It’s also worth noting that RFCs can be superceded by newer versions. If a standard is changed, a new RFC document is created, and a new number is associated with it. An RFC contains the definitive information for any Internet standard. If you’re just starting out in the world of networking, get in the habit of using RFCs when you need clarification. You can be sure that the information they provide outlines the facts and they are a freely available resource, too. Just make certain that you’re reading the most current version.

Tip: One of the best resources for searching RFCs is The results supplied by this page outline RFC status information, as well as whether a particular RFC has been updated or is now obsolete.

A number of key protocols make up the TCP/IP suite, some of which we looked at briefly in Chapter 1. In this chapter we’ll go into more detail on each. A solid understanding of the protocols that make up the TCP/IP protocol stack is not only imperative for the exams, but also in real life. Troubleshooting any network is relatively simple when you truly understand how communication processes take place

TCP/IP and the OSI Model

The TCP/IP protocol stack is comprised of protocols that exist at the upper three layers of the TCP/IP model (the lower layer is the Network Interface layer, and is responsible for network technologies that we’ve already looked at such as Ethernet, Token Ring, and so forth). The main protocols that can be found at each layer have different roles and responsibilities, and having an appreciation of how they work (and their purposes) is imperative. The figure below outlines the protocols that we’re going to look at in this section, and how they map to the OSI model.

Figure: TCP/IP protocols and the OSI model.

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)