In this article of CCNA course, we’ll see what are the Internet Layer Protocols.

In the DoD model, there are two main reasons for the Internet layer’s existence: routing and providing a single network interface to the upper layers.
None of the upper or lower layer protocols have any functions relating to routing that complex and important task belongs entirely to the Internet layer.
The Internet layer’s second duty is to provide a single network interface to the upper layer protocols. Without this layer, application programmers would need to write “hooks” into every one of their applications for each different Network Access Protocol.
This would not only be a pain in the neck, but it would lead to different versions of each application one for Ethernet, another one for Token ring, and so on. To prevent this, IP provides one single network interface for the upper layer protocols. That accomplished, it’s then the job of IP and the various Network Access protocols to get along and work together.
All network roads don’t lead to Rome they lead to IP. And all the other protocols at this layer, as well as those at the upper layers, use it. Never forget that. All paths through the DoD model go through IP. The following sections describe the protocols at the Internet layer:
- Internet Protocol (IP)
- Internet Control Message Protocol (ICMP)
- Address Resolution Protocol (ARP)
- Reverse Address Resolution Protocol (RARP)
- Proxy ARP
Let’s take look to all of the above one by one.
Internet Protocol (IP)
Internet Protocol (IP) essentially is the Internet layer. The other protocols found here merely exist to support it. IP holds the big picture and could be said to “see all”, in that it’s aware of all the interconnected networks. It can do this because all the machines on the network have a software or logical, address called an IP address, which I’ll cover more thoroughly later in foregoing articles.
IP looks at each packet’s address. Then, using a routing table, it decides where a packet is to be sent next, choosing the best path. The protocols of the Network Access layer at the bottom of the DoD model don’t possess IP’s enlightened scope of the entire network; they deal only with Physical links (local network).
Identifying devices on networks requires answering these two questions: which network is it on? And what is its ID on that network? The first answer is the software address, or logical address (the correct street). The second answer is the hardware address (the correct mailbox).
All hosts on a network have a logical ID called an IP address. This is the software, or logical address and contains valuable encoded information, greatly simplifying the complex task of routing.
IP receives segments from the Host-to-Host layer and fragments them into datagrams (Packets) if necessary. IP then reassembles datagrams back into segments on the receiving side. Each datagram is assigned the IP address of the sender and of the recipient. Each router (layer 3 device) that receives a datagram makes routing decisions based on the packet’s destination IP address.
The following figure shows an IP header. This will give you an idea of what the IP protocol has to go through every time user data is sent from the upper layers and is to be sent to a remote network.

The following fields make up the IP header.
Version: IP version number
Header length: Header Length (HLEN) in 32-bit words.
Priority and Type of Service: Type of service tells how the datagram should be handled. The first 3 bits are the priority bits.
Total Length: Length of the packet including header and data.
Identification: Unique IP packet value.
Flags: Specifies whether fragmentation should occur.
Fragment Offset: Provides fragmentation and reassembly if the packet is too large to put in a frame. It also allows for different maximum transmission units (MTUs) on the Internet.
Time to Live: The time to live is set into a packet when it is originally generated. If it doesn’t get to where it wants to go before the TTL expires, boom it’s gone. This stops IP packets from continuously circling the network looking for a home.
Protocol: Port of upper layer protocol (TCP is port 6 or UDP is port 17 [hex]). Also supports Network layer protocols, like ARP and ICMP can be called Type field in some analyzers. We’ll talk about this field in more detail in a minute.
Header checksum: Cyclic redundancy check (CRC) on header only.
Source IP address: 32-bit IP address of sending station.
Destination IP address: 32-bit IP address of the station this packet is destined for.
Options: Used for network testing, debugging, security, and more.
Data: After the IP option field will be the upper layer data.
Here’s a snapshot of an IP packet caught on a network analyzer (notice that all the header information discussed previously appears here):
IP Header | Internet Protocol Datagram |
Version | 4 |
Header length | 5 |
Precedence | 0 |
Type of service | %000 |
Unused | %00 |
Total length | 187 |
Identifier | 22486 |
Fragmentation flags | %010 Do Not Fragment |
Fragment Offset | 0 |
Time to Live | 60 |
IP type | 0x06 TCP |
Header checksum | 0xd031 |
Source IP address | 10.7.1.30 |
Destination IP address | 10.7.1.10 |
No Internet Datagram Options |
The type field it’s typically a protocol field, but this analyzer sees it as an IP Type field is important. If the header didn’t carry the protocol information for the next layer, IP wouldn’t know what to do with the data carried in the packet. The preceding example tells IP to hand the segment to TCP.
The following figure demonstrates how the Network layer sees the protocols at the Transport layer when it needs to hand a packet to the upper layer protocols.

In this example, the protocol field tells IP to send the data to either TCP port 6 or UDP port 17 (both hex addresses). But it will only be UDP or TCP if the data is part of a data stream headed for an upper layer service or application. It could just as easily be destined for Internet Control Message Protocol (ICMP), Address Resolution Protocol (ARP), or some other type of Network layer protocol.
Protocol | Protocol Number |
ICMP | 1 |
IP in IP (tunneling) | 4 |
IGRP | 9 |
EIGRP | 88 |
OSPF | 89 |
IPv6 | 41 |
GRE | 47 |
Layer 2 tunnel (L2TP) | 115 |
Internet Control Message Protocol (ICMP)
Internet Control Message Protocol (ICMP) works at the Network layer and is used by IP for many different services. ICMP is a management protocol and messaging service provider for IP. Its messages are carried as IP datagrams. RFC 1256 is an annex to ICMP, which affords the host’s extended capability in discovering routes to gateways.
ICMP packets have the following characteristics:
- They can provide with information about network problems.
- They are encapsulated within IP datagrams.
The following are some common events and messages that ICMP relates to:
Destination Unreachable: If a router can’t send an IP datagram any further, it uses ICMP to send a message back to the sender, advising it of the situation. For example, take a look at the following figure.

When Host A sends a packet destined for Host B, the Lab_B router will send an ICMP destination unreachable message back to the sending device (Host A in this example).
Buffer Full: If a router’s memory buffer for receiving incoming datagrams is full, it will use ICMP to send out this message until the congestion abates.
Hops: Each IP datagram is allotted a certain number of routers, called hops, to pass through. If it reaches its limit of hops before arriving at its destination, the last router to receive that datagram deletes it. The executioner router then uses ICMP to send an obituary message, informing the sending machine of the demise of its datagram.
Ping: Packet Internet Groper (Ping) uses ICMP echo request and reply messages to check the physical and logical connectivity of machines on an internetwork.
Trace route: Using ICMP time-outs, Trace route is used to discover the path a packet takes as it traverses an internetwork.
Flags | 0x00 |
Status | 0x00 |
Packet length | 78 |
Timestamp | 14:04:25.967000 12/20/03 |
Ethernet Header | |
Destination | 00:a0:24:6e:0f:a8 |
Source | 00:80:c7:a8:f0:3d |
Ether-type | 08-00 IP |
IP header | Internet Protocol Datagram |
Version | 4 |
Header length | 5 |
Precedence | 0 |
Type of service | %000 |
Unused | %00 |
Total length | 60 |
Identifier | 56325 |
Fragmentation flags | %000 |
Fragment offset | 0 |
Time to Live | 32 |
IP Type | 0x01 ICMP |
Header checksum | 0x2df0 |
Source IP address | 100.100.100.2 |
Destination IP address | 100.100.100.1 |
No internet datagram options | |
ICMP | Internet Control Message Protocol |
ICMP type | 8 Echo Request |
Code | 0 |
Checksum | 0x395c |
Identifier | 0x0300 |
Sequence number | 4352 |
ICMP Data Area | |
Abcdefghijklmnop | 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d |
Qrstuvwabcdefghi | 71 72 73 74 75 76 77 61 62 63 64 65 66 |
Frame Check Sequence | 0x00000000 |
Notice anything unusual? Did you catch the fact that even though ICMP works at the Internet (Network) layer, it still uses IP to do the Ping request? The Type field in the IP header is 0x01, which specifies that the data we’re carrying is owned by the ICMP protocol. Remember, just as all roads lead to Rome, all segments or data must go through IP!
If you remember reading about the Data Link layer and the different frame types, you should be able to look at the preceding trace and tell what type of Ethernet frame this is. The only fields are destination hardware address, source hardware address, and ether-type. The only frame that uses an ether-type field exclusively is an Ethernet_II frame.
But before we get into the ARP protocol, let’s take another look at ICMP in action. The following figure shows an internetwork (it has a router, so it’s an internetwork, right?)

Server1 (10.1.2.2) telnets to 10.1.1.5 from a DOS prompt. What do you think server1 will receive as a response? Since Server1 will send the Telnet data to the default gateway, which is the router, the router will drop the packet because there isn’t a network 10.1.1.0 in the routing table. Because of this, Server1 will receive a destination unreachable back from ICMP.
Address Resolution Protocol (ARP)
Address Resolution Protocol (ARP) finds the hardware address of a host from a known IP address. Here’s how it works: When IP has a datagram to send, it must inform a Network Access protocol, such as Ethernet or Token Ring, of the destination’s hardware address on the local network. (it has already been informed by upper layer protocols of the destination’s IP address.) If IP doesn’t find the destination host’s hardware address in the ARP cache, it uses ARP to find this information.
As IP’s detective, ARP interrogates the local network by sending out a broadcast asking the machine with the specified IP address to reply with its hardware address. So basically, ARP translates the software (IP) address into a hardware for example, the destination machine’s Ethernet board address and from it, deduces its whereabouts on the LAN by broadcasting for this address. The following figure shows how an ARP looks to a local network.

The following trace shows an ARP broadcast notice that the destination hardware address is unknown and is all Fs in hex (all 1s in binary) and is a hardware address broadcast:
Flags | 0x00 |
Status | 0x00 |
Packet length | 64 |
Timestamp | 09:17:29.574000 12/06/03 |
Ethernet header | |
Destination | FF:FF:FF:FF:FF:FF Ethernet Broadcast |
Source | 00:A0:24:48:60:A5 |
Protocol type | 0x0806 IP ARP |
ARP | Address Resolution Protocol |
Hardware | 1 Ethernet (10Mb) |
Protocol | 0x0080 IP |
Hardware Address Length | 6 |
Protocol Address Length | 4 |
Operation | ARP Request |
Sender Hardware Address | 00:A0:24:48:60:A5 |
Sender Internet Address | 172.16.10.3 |
Target Hardware Address | 00:00:00:00:00:00 (Ignored) |
Target Internet Address | 172.16.10.10 |
Extra bytes (padding) | ………0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A |
Frame Check Sequence | 0x00000000 |
Reverse Address Resolution Protocol (RARP)
When an IP machine happens to be a diskless machine, it has no way of initially knowing its IP address. But it does know its MAC address. Reverse Address Resolution Protocol (RARP) discovers the identity of the IP address for diskless machines by sending out a packet that includes its MAC address and a request for the IP address assigned to that MAC address.
A designated machine, called a RARP server, responds with the answer and the identity crisis is over. RARP uses the information it does know about the machine’s MAC address to learn its IP address and complete the machine’s ID portrait.
The picture given below shows a diskless workstation asking for its IP address with a RARP broadcast.
Proxy Address Resolution Protocol (Proxy ARP)
On a network, your hosts can’t have more than one default gateway configured. Think about this…what if the default gateway (router) happens to go down? The host won’t just start sending to another router automatically you’ve got to reconfigure that host. But Proxy ARP can actually help machines on a subnet reach remote subnets without configuring routing or even a default gateway.

One advantage of using Proxy ARP is that it can be added to a single router on a network without disturbing the routing tables of all the other routers that live there too. But there’s a serious downside to using Proxy ARP. Using Proxy ARP will definitely increase the amount of traffic on your network segment, and hosts will have a larger ARP table than usual in order to handle all the IP-to-MAC-address mappings. And Proxy ARP is configured on all Cisco routers by default you should disable it if you don’t think you’re going to use it.
One last thought on Proxy ARP is that it isn’t really a separate protocol. It is a service run by routers on behalf of other devices (usually PC’s) that are separated from their query to another device by a router, although they think they share the subnet with the remote device.