If you read my article on the OSI model, you got a good overview on communications from that model's perspective, but how does that relate to TCP/IP? We're going to take it a step further, getting into the idea behind the two address concept. How does an IP address and a MAC address work together? If you want to hijack sessions and all sorts of lulz like that, you need to understand these concepts. Let's get into it, mates!
A good way to understand what a protocol is, would be to view it like a language. If people were network interfaces and all spoke their own language, there would be no way for them to properly communicate. A protocol works the same way, by agreeing to use certain methods or standards, many groups can build and create things that can all communicate with each other. So when you see TCP/IP protocol, think of it like a collection of rules computers must all follow to allow the millions and millions of networked machines called the Internet to function.
OSI was never meant to be just a model. Back in the 1970s, it was a competing protocol against TCP/IP and was actually a better protocol in design. The main reason it didn't take hold was that its addresses were hexadecimal and very complex. In fact, it was thought back then, that it had too many available addresses. Being based in hex, it allowed far more than the current protocol standard of IPv4. I should point out that the next version of IP, version 6, uses hex addresses which allow many more available ranges then IPv4. Go figure.
Examples of addresses include:
- Hexadecimal - 12:34:56:78:9A:BC
- IPv4 (current standard) - 184.108.40.206
- IPv6 (new format) - fe80::223:4eff:fec0:5b48
OSI is still used today to describe network communication and for standards to unite, while the TCP model is used to show relation between the various protocols it contains. Below is a diagram of how the two map out to each other.
The first thing you might notice is that TCP/IP is not just one protocol, but an entire suite of protocols. Next, you should notice that the layers of the TCP/IP architecture and the OSI model line up more or less the same.
Layers one and two of the OSI model are considered to both be physical and local, so they are simply grouped together as the Network Interface Layer under TCP/IP. The Network layer is just renamed the Internet layer and carries the same functions. Following that, you can see layers five through seven of OSI have been compiled into the Application layer, as that is where they operate.
Still with me? Now let's take a look at all of these three- and four-letter abbreviations in the suite. This is the good stuff coming up here.
The TCP/IP suite is where we talk about things like FTP, DNS and other protocols you might have heard and read about before. Again, looking at the picture above, we can see what protocols are used in what layers.
An entire book could be written on the TCP/IP suite—and they have. To keep things in focus, we are only going to discuss a few protocols here. Feel free to ask any other questions about the protocols in the comments.
A good example of this is the Transport layers of both the OSI and TCP models. When data arrives there, it has two options for transport, TCP and UDP. TCP allows for reliable transit, where as UDP is unreliable. If you are wondering why you would ever want to send something unreliable, here is the answer...
In a very short nutshell, when you send a request with TCP, you will always get a confirmation of its receipt. This is like me throwing you a ball, you yelling "I got it!", then throwing it back to me, where I would then yell "I got it". But what if I drop it? I would simple yell back, "I need it again!", and would wait until you threw me a new one.
In contrast, UDP is like you throwing me ball after ball and just hoping I catch them. If I drop one or sixteen—it doesn't matter—because you have no way to know.
UDP sounds pretty bad right now, but listen to this: services like VOIP and online games are too fast for TCP. Imagine you were playing Halo and you dropped a packet or two. Can you stop and wait for it? Of course not. You would see a little jump in the frame rate and you'd keep going. If you had to wait for it to get back to you, you would surely be fragged. The same applies if you were talking to your mate on Skype and you dropped a few packets; it makes no sense to pause the conversation to retrieve them.
TCP is great when you need to make sure all the packets arrive and in order. Web browsing and the like would be awfully hard without having reliable transportation.
It is the Transport layer that determines, based on its parameters, what protocol to use.
Every single packet being sent around has two addresses inside of it—an Internet Protocol and a Media Access Control address. An IP address really only identifies your network, as all internal IP addresses are actually private and handled by Network Address Translation (NAT) at the router. You might have an IP address from your ISP of 220.127.116.11 that identifies your network, and your actual computer might have a private, inside-the-network address of 192.168.1.67.
This is done so that many devices, like your PlayStation and your computer, can get on the Internet at the same time, while only needing one IP address. If every single device online today had its own address, we would have already ran out of new ones to use!
So, where does a MAC address come in? As it is, IP addresses are of no use inside of your network, as your machines don't use them to talk to each other.
Where IP addressing functions at the network layer, MAC addressing works at the data link layer. It's a slight oversimplification, but one can think of IP addressing as supporting the software implementation and MAC addresses as supporting the hardware implementation of the network stack. The MAC address generally remains fixed and follows the network device, but the IP address changes as the network device moves from one network to another.
So, how in the world does this actually work? Your network maintains a mapping between the IP address of a device and its MAC address. This mapping is known as the ARP Table.
ARP stands for Address Resolution Protocol and it is used to associate a Network layer address (IP address) with a Data Link layer address (MAC address).
Let's say you have some data to send. When the data gets to the Network layer, it will put on the destination IP address. All of this info (the Network layer datagram, aka packet) is passed down to the Data Link layer where it is taken and placed within a data link frame.
Based on the IP address and subnet mask, your computer should be able to figure out if the destination IP is local to your network or not. If the IP is local, your computer will look in its ARP table, the table where the responses to previous ARP requests are cached, to find the MAC address.
If it's not there, then your computer will broadcast an ARP request to find out the MAC address for the destination IP. Since this request is broadcast, all machines on the network will receive it and examine the contents. If the IP address in the request is their own, they'll reply back. On receiving this information, your computer will update its ARP table to include the new information and will then send out the frame addressed with the destination hosts MAC address.
With all this talk about protocols, I'm sure you have some questions about specific ones you have come across. It turns out the Internet Engineering Task Force has put together a memorandum describing, collecting, and categorizing details about protocols, research, and ideas on how the actual Internet functions. This is needed because there's no one authority that mandates certain protocols to be used over other ones, and in fact, you can create and submit your own for review and use!
We are another step further in giving you the skills you need to navigate the Internet like a pro. If some of this didn't quite make sense, I encourage you to check out our OSI model and Intro to IP Addresses articles for some more back knowledge. Next in the series, we will look at penetration attacks that work on these ideas!
Questions? Comments? Have anything to add to this walkthrough? Leave us a comment or visit our forum and share it with the community.