For those who begin their studies of computer networking, a common question is the one posed above in the title. What is the reason behind why a device (connected to an Ethernet network) needs to have two identifiers?This post is my attempt to answer that question.
IP Addresses and MAC addresses were developed around the same time (circa 1974) but were answers to two, very different problems.
The developers of MAC addresses (specifically Dr. Robert Metcalf who was working with Xerox at the time) had created a network type (i.e. a cable) onto which several devices could be physically connected and all have visibility to the energy (electrical signals) transmitted onto that cable. Based on that, the developers of the protocol were trying to answer questions like:
- If everyone could see/hear everyone else, how could one device transmit without overriding someone else's current transmission.
- If everyone could see/hear everyone else how could Device-A transmit to Device-B and have it understood by all other devices on that cable (which were listening to that conversation) that they should ignore what they were seeing
- If everyone could see/hear everyone else, when Device-A recognized that another device on the cable was speaking...how could Device-A determine if it should be the recipient of that conversation...or it should ignore it?
So in an environment (ie. cable) in which all devices can physically "hear" all other devices (this is how Ethernet works) the designers determined that each device simply needed a unique identifier (MAC Address) with which they could address their data. This address would not prevent everyone else on the cable from seeing the data, but it would provide an indicator as to which, specific device was the intended recipient of that data.
This is similar to the question, “if a bunch of people are in the same room and can all hear each other talking, how can one person communicate directly with another?” As a solution, we can provide each person with a unique name (such as Bob and Sally) and therefore Bob, when he decides to speak, can simply shout out “Hey Sally, this is Bob. I need to talk to you.” All others in the room will hear Bob’s voice, but elect to ignore it once they understand that he is trying to communicate with Sally.
But that entire premise breaks down if you have devices which cannot hear each other directly and instead, need some kind of relay agent to communicate (i.e. a router).
An example of this would be if Bob is in Room-1 on the first floor of a building, and Sally is in room-x on the 20th story of that same building. Bob can’t simply “speak” and expect that Sally will be able to hear him. Or what if Bob is blind? He is told, “you are in Room-1 and there are other rooms in this building. People you want to communicate with may-or-may-not be in the same room as you. Figure it out.” At this point if he wants to speak to Sally he doesn’t even know if Sally is in the same room as him...or in a different room.
The developers of the Internet Protocol had a totally different set of challenges they were trying to address. The questions they were trying to address were:
- Start with the assumption that one doesn't KNOW what the physical network looks like (like Bob described above when he is blind). It MAY be of the type where devices can communicate directly (i.e. see each other's electrical signals on a common wire) or it might be of the type where devices are separated across vast geographical distances...unable to communicate directly...and requiring the services of one-or-more intermediary relays (i.e. routers).
- If an end host (Device-A) is connected to a cable and determines that it needs to communicate to Device-B, how will it address its data to Device-B if it doesn't know…
- Is Device-B on the same cable as Device-A and able to directly intercept its electrical transmissions, or...?
- Is Device-B not able to directly intercept Device-A's electrical transmissions, but it IS reachable via one-or-more relay devices?
In order to answer that question, the designers of IP decided that network segments (i.e. “rooms” in my example above) would be identified/addressed geographically (what we refer to as the "network" or "prefix" portion of an IP Address). Then, each device would be provided with an address identifying its geographical "network" as well as identifying itself as a unique host on that given network.
In this way, when Device-A wanted to communicate with Device-B all it had to do was compare its own (Device-A's) IP address with the destination's (Device-B's) IP address to determine if direct host-to-host communication was possible (is the device on MY network...or a different network? Can I communicate directly or do I need to forward my data to a local relay agent?).
Remember...the developers of Ethernet just assumed that all devices would be on the same network and all capable of hearing each other, so there was no need to build any kind of "geography" into the address.
About the Author:
Keith Bogart started his career at Cisco Systems in 1996 as a customer service representative and quickly rose to a Cisco Technical Assistance Center (TAC) engineer on the “Dial-Access” team. After almost 17 years at Cisco, Keith began his career as an instructor with INE. For the past four years Keith has been creating and teaching many of our online Cisco courses and instructing our live CCNA and CCNP Bootcamps. Keith holds several certifications – CWNA, CCNA Security and CCIE Dial-ISP. You may contact Keith at email@example.com or find him helping others in our IEOC community forum.