So here’s a question that really bothered me for the longest time:
Why do computers have both physical, MAC addresses and also IP addresses? Why does your computer need two addresses to connect to a network? Isn’t an IP address sufficient? What is a MAC address anyway?
This is going to be fun. Keep reading for my enlightening explanation.
First let’s talk about MAC addresses because they’re not as famous as their pretentious cousins, IP addresses.
Magical Mac Addresses
Usually, when someone says Mac they think of the titular computer that elicits cupidity in children and mania in men.
Admittedly, the Mac is a thing of beauty but when we hear the term “Mac Addresses” we’re talking about an entirely different beast.
A MAC Address, also known as a Physical Address or Burned-in-Address, is just a device identifier. It’s a long number, 6 bytes to be exact, usually written in base-16 (Hexadecimal) and represents a unique device address for the purposes of communicating with other devices on a network.
The device can be anything from a PC or a Printer, a TV or a toaster, an X-box or Xerox copier – if it needs to communicate with other devices it most likely has a MAC address.
You can easily view your MAC address in Windows so you should take a look at your own MAc. The first half of the MAC address identifies the vendor of your network interface and the last half is an arbitrary assignment from that vendor.
So in theory, every MAC address in the world is one of a kind. It’s kind of like your unique digital fingerprint.
But wait, what about IP addresses?
Initially it might seem that IP addresses and MAC addresses are redundant because both are unique identifiers of networked devices. These networked devices are known as hosts and need IP addresses so they can communicate with other hosts.
So if IP addresses help hosts communicate with each other… why do we need MAC addresses?
I’ll show you but first I’ve got to explain a little bit about TCP/IP.
A quick TCP/IP primer
TCP/IP is the most prevalent networking protocol stack in existence.
Think of TCP as the stuff computers would talk about if they were at a cocktail party or networking event (pun intended).
Just as humans use different languages to communicate ideas and feelings, so computers have their own way of conveying data. The “language” is known as a protocol and defines the rules of communication between computers.
Back in the nacient beginnings of the internet it felt like every vendor on earth had their own language for talking with other computers. In the early 80’s, IBM had its thing, Apple had its thing, Xerox had its thing and it was a mess.
So a bunch of smart people at the Department of Defense and International Organization for Standardization started independently, but concurrently, working on a unified, standard of communication.
Both the OSI model and TCP/IP came out of that era but TCP/IP eventually won the day because OSI standardization moved at a glacial pace. It took way too long to formalize the OSI model so everyone just went with TCP/IP.
Let’s tango with TCP/IP
TCP/IP is a hierarchical suite of protocols that defines how computers communicate with each other.
It’s hierarchical because each protocol grouping, known as a layer, provides a service to the layer above it.
There are five layers in TCP/IP:
- Data Link
The Data Link layer contains the specifications for Ethernet framing while the Internet Layer defines the IP protocol which is responsible for addressing.
By the way, “framing” is just the technical word for when the Data Link layer packages the contents with a Ethernet Header and Trailer. It’s like a little frame because the padding goes on both sides of the payload.
Whenever a host communicates with another host the data moves down the TCP/IP stack and scoops up a new header along the way.
So when you went to fixedbyvonnie.com, your web browser handed off the processing of the URL to the HTTP protocol which lives in the Application layer.
The Application layer slapped on its own header, an HTTP header in this case, that had a bunch of information about the site fixedbyvonnie.com. If you’re using Chrome, the HTTP header basically says something like this:
Hey! My name is Chrome and I want index.php from fixedbyvonnie.com!
It’s technically called an HTTP GET request and just tells the web server that you want to get a specific file document.
Next, TCP/IP passed the data down to the Transport layer, which is where a bunch of stuff such as UDP and TCP live. Since we’re dealing with a website in this case, the Transport layer slaps on its TCP header with a bunch of other stuff and passes the segment down to the Internet Layer.
Here in the Internet Layer, the segment gets another header.
It’s all about the headers.
There’s a lot of stuff in the Internet Layer header too but for the purpose of this post I’ll just mention the destination and source IP addresses. The transport layer segment is known as an Internet packet at the Internet Layer.
By the time it gets to the Data Link layer, it’s called a frame and gets cushioned on both ends with Ethernet stuff. I’m being intentionally vague because if I explain what that “stuff” is it’ll have your head whirling around like the poltergeist. So for now, I’ll hide the details with the word “stuff”.
So what’s in the Ethernet header? It comprises source and destination MAC addresses and an Ethernet trailer which is just a long number which helps the destination host verify that the frame wasn’t damaged in transit.
I know there are a lot of headers going on but the important thing to notice is that the unit of data that contains your simple HTTP GET request gets heavier and heavier as it moves down the TCP/IP stack. Each layer adds its own information until it gets to the Physical Layer where it is physically encoded onto copper as electrical voltages or fiber optic media as light pulses.
The reverse happens at the destination.
The raw data signal enters the destination at the Physical Layer and each header is stripped off as it enters the same layer name from the source computer.
Okay I know that sounds confusing. Think of it like this:
When my server sees your HTTP GET request, it arrives in a long string of ones and zeros. But because both your computer and my server understand TCP/IP , my server knows how to interpret the boundaries in the binary string and therefore can make sense of the data coming in.
As the data moves up the TCP/IP stack on the server the various headers are dropped until the only thing that remains is the original, unadorned HTTP GET request you sent.
Here’s why MAC addresses matter
After typing and entering fixedbyvonnie.com into the address bar your PC tries to figure out if the computer named fixedbyvonnie.com is located on your local network or somewhere else in the world.
It uses DNS to do that, but without getting too technical, it figures out that fixedbyvonnie.com is not on your local network because the IP address that represents fixedbyvonnie.com has a different grouping than your local IP address.
For example, fixedbyvonnie.com is 184.108.40.206. The first few dotted numbers, 198.57.208, tell your computer that it’s in a different network than your PC because the first few dotted numbers of your computer’s IP address is different.
So your HTTP GET makes its journey through the TCP/IP stack. When it gets to the Data Link layer, your computer says something like this:
Alright, so I know fixedbyvonnie.com is in a different network than the source PC but I have no idea how to get there. Hmm… how can I get this HTTP GET request to fixedbyvonnie.com from this computer? Ah, wait a second, my little home router knows more than me. I’ll forward this request to my default gateway by sending the frame to the MAC address of the default gateway configured for this computer.
So the frame containing the HTTP GET request gets on a little boat and gets shipped directly to your local router.
The data frame still contains information from all the upper layer protocols. So the IP Address of the destination computer, 220.127.116.11 is still sitting in the IP header. Along with the IP address of your PC and all that other stuff from the other layers above it.
Here’s the million dollar concept to understand:
The source and destination IP addresses sitting in the IP header never change during the duration of the trip. In other words, as the data packet traverses the network, both the source and destination IP Addresses are static. They don’t change.
But the MAC addresses headers are constantly being changed.
Every time the packet is passed from one router to the next, the MAC address header and trailer is stripped from the packet and replaced with a new set. The new set always contains the source MAC address of the router that just received the packet and the destination MAC is always the MAC of the next hop router.
So do you see what’s going on?
The MAC address just gets the data packet to the next device but the IP address is responsible for getting it to the ultimate destination.
A little analogy might help here
Let’s say there are three routers between your computer and my server.
Let’s name these devices as follows:
- A is Your computer
- B is Router 1
- C is Router 2
- D is Router 3
- E is fixedbyvonnie.com
In order to get the data packet from A to B, the Data Link layer of TCP/IP frames the packet with an Ethernet header that has B’s MAC address in the destination field and A’s MAC address in the source field.
Now think of the layers again:
- Data Link
Remember, on the sending computer, each layer is encapsulated with a header from the layer above it. So the Internet Layer contains your source IP address and the IP address of fixedbyvonnie.com.
That packet is then encapsulated, basically wrapped, in an Ethernet frame with the MAC address containing your source MAC and the MAC of Router 1 (which is probably your home router).
When Router 1 get’s the frame it examines the destination IP address and compares it to a table of IP address families.
If I could read the routers mind it would think something like this:
Hey, do I know of any IP groups that contains the IP address of fixedbyvonnie.com? Um… nope I’ll ask my neighbor Router 2.
To get the frame to Router 2, Router 1 chucks the Ethernet headers containing the source MAC of your computer and replaces it with its own source MAC address. At the same time, it strips off the destination MAC which was Router 1 and replaces it with the MAC of Router 2.
The entire time the source IP address and the destination IP address in the packet is untouched.
This process continues until the packet eventually arrives at the destination. Each network device in the transmission path changes the source and destination MAC to get the packet to the very next device.
The IP address is just there for the big picture but the MAC is how the packet actually gets from one place to the next. If all you had was an IP address your computer would have no idea what to do with the packet.
This is obviously a simplified explanation of how MAC and IP addresses work but it’s the basics. If you want to know the details just chime in the comments below!
Pingback: Are you being tracked by your MAC address? - fixedByVonnie()
Pingback: WireShark 101 - fixedByVonnie()
Pingback: Installing GNS3 in Mac OS X Yosemite - fixedByVonnie()
Pingback: Welcome to Kali Linux (Part 1 of 3) - fixedByVonnie()
Pingback: Networking 101: The lowdown on how Networks really work (Part 1 of 2) - fixedByVonnie()