After discussing the makeup of the OSI Model and some of the Key Players involved in moving a packet from one host to another, we can finally discuss the specific functions which occur in allowing Host to Host communication.
At the very core of the Internet is this idea that two computers can communicate with each other. Although it is rare to find situations where two hosts are connected directly to each other, understanding what happens if they were is crucial to understanding everything else that happens when multiple hosts are communicating through a switch or router.
As such, this article will focus on host to host communication, and each individual step involved in the process.
Host to Host Communication
Since there are no Routers in this illustration, we know all the communication is happening within the same network — therefore, Host A and Host B are both configured with IP addresses that belong to the same network.
Host A starts by generating some Data for Host B. Host A knows the final destination for this data will be the IP address 10.10.10.20 (Host B). Host A also knows its own address (10.10.10.10), and as such is able to create a L3 header with the required Source and Destination IP Address.
But as we learned earlier, packet delivery is the job of Layer 2, so despite these hosts being directly connected to one another, a L2 header must be created.
The Source of the L2 header will be Host A’s MAC address (aaaa.aaaa.aaaa). The Destination of the L2 header should be Host B’s MAC address, but at the moment, Host A doesn’t have an entry in its ARP Table for Host B’s IP address, and therefore, does not know Host B’s MAC address.
As a result, Host A is unable to create the proper L2 header to deliver the packet to Host B’s NIC at this time. Host A will have to initiate an ARP Request in order to acquire the missing information:
The ARP Request is a single packet which essentially asks: “If there is someone out there with the IP 10.10.10.20, please send me your MAC address.“
Remember, at this point Host A does not know if Host B exists. In fact, Host A does not know that it is directly connected to Host B. Hence, the question is addressed to everyone on the link. The ARP Request is sent as a Broadcast, and had there been other hosts connected to this link, they too would have received the ARP Request.
Also note that Host A includes its own MAC address in the ARP Request itself. This allows Host B (if it exists) to easily respond directly back to Host A with the requested information.
Receiving the ARP Request allows Host B to learn something. Namely, that Host A’s IP address is 10.10.10.10 and the correlating MAC address is aaaa.aaaa.aaaa. Notice this entry is now added to Host B’s ARP Table.
Host B can use this new information to respond directly to Host A. The ARP Response is sent as a Unicast message, directly addressed to Host A. Had there been other hosts on this link, they would not have seen the ARP Response.
The ARP Response will include the information Host A requested: The IP Address 10.10.10.20 is being served by the NIC with the MAC address bbbb.bbbb.bbbb. Host A will use this information to populate its ARP Table:
With Host A’s ARP Table populated, Host A can now successfully put together the proper L2 header to get the packet to Host B.
When Host B gets the data, it will be able to respond without further ado, since it already has a mapping in its ARP Table for Host A.
Again, it is rare to find two hosts directly connected to each other. But understanding what it takes to get a packet from one Host to another Host is key to understanding how a Switch enables multi-host communication, or a Router enables multi-network communication. Both of these will be the subjects of the next articles in this series.
The key thing to note is a host doesn’t know whether it is connected to a switch or directly to another host. In either case, the host will follow the process outlined above when trying to communicate with another host.