The Real Reason We Have Both IP and MAC Addresses

Let’s redesign the internet.

We should probably start by understanding how the internet works.

It’s a network of networks. Each network can be thought of as a walled village. Each host in a network can be thought of as a house in that village. Nothing gets into or out of a village except through a gateway in the wall.

Built into the outside of the wall next to the gateway is a stable with a guy on a horse. His name is Henry the Horse. His job is to take messages from the village gateway to the gateways of the neighbouring villages. And to bring messages destined for his home village back to its gateway.

Built into the inside of the wall next to the gateway is a post office with a guy with a well worn leather satchel. His name is Pat the Post. He looks at the messages and hands any that are addressed to houses in other villages to Henry the Horse. His job is to collect any incoming messages from other villages from Henry the Horse. All the messages that are addressed to houses in Pat the Post and Henry the Horse’s village go into Pat the Post’s satchel. He wanders round the village delivering the messages in his satchel to the correct houses and collecting messages the residents want delivering.

Start with the hypothetical: What would we need to change if we were no longer allowed to use MAC addresses?

It’s often said that MAC addresses are unique to each NIC. Not true.

We’re running out of IP addresses (assuming we’re talking just v4 at least). MAC addresses have a similar problem. Three bytes for manufacturer leaves only three bytes for each of their NICs.

Main point to make is that MAC addresses are flat and that we need a hierarchy (like IP) to reduce the difficulty of creating and maintaining routes from one host to another. So why not just IP? Because (for example) automatic allocation of IP addresses requires knowing the ID of the host asking for an address. Otherwise a host could ask for multiple IPs, potentially infinitely many.

But it’s easy to spoof a MAC so this can still be done.

Let’s assume we only have MAC addresses and IP addresses. That’s not true at all but it’ll do as an approximation. They’re both used to identify a host. This would lead you to think we only need one or the other. But it’s a bit more subtle than that. Let’s look at the consequences of getting rid of one or the other.

Getting Rid Of IP Addresses

This leaves us dealing with only MAC addresses as a mechanism for getting data from one host to another. While MAC addresses are often described as being unique, fixed identifiers burned into the hardware device, this is really just a nice simplified model that is ‘good enough’ and a useful way to think about them. The reality is far more complicated but we’ll keep it simple.

So, if I want get data from host A to host B, I just use the MAC address for host A as the source address and the MAC address for host B as the destination address. The obvious next question is how do we get the data from host A to host B. Host A squirts an ARP request out onto the wire as a broadcast to every host on the network. Everything stays silent apart from the host that has that MAC or the router if none do. The router knows what MACs are attached to it’s network so it responds when it sees a MAC not in its list. Host A send the data to the host or router that replied to the ARP request. Host A is done. A local Host B processes the data. The router checks its rouing table to find the route to Host B’s MAC and chucks it to the next hop.

So that would work.

Getting Rid Of MAC Addresses

This leaves us dealing with only IP addresses as a mechanism for getting data from one host to another. IP addresses are mutable, ephemeral IDs grouped so as to reflect network layout.

We can do exactly the same process we discussed for MAC addresses for IPs

So in principle we could route from Host A to Host B using either MAC or IP. We don’t need both.

IP addresses. That’s how one host tells the network where to send its data. Familiar stuff. But we also have MAC addresses. ¿Por qué los dos? Why can’t we just use IP addresses? Or MACs? You should train yourself to come up with queries like this. Question received wisdom. Not because received wisdom is likely to be wrong, especially if you’re a noob, but because it’s usually right. But for subtle and enlightening reasons.

Turns out we have both IP and MAC addresses for both historical reasons and for solid engineering reasons. If you Google the question you’ll find lots of answers along the lines of Layer 3 vs Layer 2 and other implementation details

The fact that TCP/IP runs well over all kinds of underlying networks is no coincidence. Today, every imaginable kind of computer is connected to the Net, even though those connected over the fastest links, such as Gigabit Ethernet, can transfer more data in a second than the slowest, connected through wireless modems, can transfer in a day. This flexibility is the result of the philosophy that network failures shouldn’t impede communication between two hosts and that no assumptions should be made about the underlying communications channels. Any kind of circuit that can carry packets from one place to another with some reasonable degree of reliability may be used. This philosophy makes it necessary to move all the decision-making to the source and destination hosts: it would be very hard to survive the loss of a router somewhere along the way if this router holds important, necessary information about the connection.

But the routers do hold important necessary information about the connection. That’s the whole point of them. A source host has zero clue how to get its data to the destination host. It just throws it out onto the network.

This way of doing things is very different from the way telephony and virtual circuit-oriented networks such as X.25 work: they go through a setup phase, in which a path is configured at central offices or telephone switches along the way before any communication takes place. The problem with this approach is that when a switch fails, all paths that use this switch fail, disrupting ongoing communication. In a network built on an unreliable datagram service, such as the Internet, packets can simply be diverted around the failure and still be delivered. The price to be paid for this flexibility is that end hosts have to do more work. Packets that were on their way over the broken circuit may be lost; some packets may be diverted in the wrong direction at first, so that they arrive after subsequent packets have already been received; or the new route may be of a different speed or capacity. The networking software in the end hosts must be able to handle any and all of these eventualities.

Talk about NAT. If I’m running a server on 192.168.1.1 there’s no way for the sender to know which 192.168.1.1 (not globally unique) out of all the hosts with that IP so it sends it to my router (with a unique IP) and my router decides which local host to send it to (it knows I’m running the service it received data for on 192.168.1.1)

Need a hierarchy - What Three Words (bad example - not everyone familiar with it) is flat but Country, City, Street, House, Person is hierarchical. A mail sorter in Kenya doesn’t need to know the completely defined address of every person in the world to get a letter to Steve the plasterer in Canada; he just sends it to Canada and leaves the local delivery to the Canadian postal workers.

Indirection/dereferencing - separation of concerns

Ability to change MAC without confusing IP

Routing will be difficult - logical vs physical. It doesn’t matter if your network cards all have a similar MAC address or not; we’ll group our computers so that all TCP/IP address that began with 10.0.x.x. are part of the engineering group, and those of 10.1.x.x. are the printers

Some layer-2 protocols (the IEEE LAN protocols, e.g. ethernet, Wi-Fi, etc.) use MAC addresses, but others (PPP, HDLC, frame relay, ATM, etc.) use something else or nothing at all. The IEEE maintains its layer-1/2 protocols, and the IETF maintains the layer-3 IPv4 and IPv6 protocols. They are two completely separate entities. Layer-2 protocols do not care which layer-3 protocols they carry, and layer-3 protocols do not care which layer-2 protocol carries them.

MAC addresses and IP addresses operate on different layers of the internet protocol suite. MAC addresses are used to identify machines within the same broadcast network on layer 2, while IP addresses are used on layer 3 to identify machines throughout different networks.

That explains why it’s needed given the current architecture. But why was the architecture designed that way in the first place? I could easily imagine a world where there are only local IP addresses and WAN IP addresses.

There isn’t anything physically stopping you from designing a network which has just IP addresses for L2 and L3. Then ‘ethernet switch’ would learn the SIP address of incoming packets and flood or forward towards a DIP address. However, this network would only ever support IP, when the next-generation of IPvX come’s, it would not work, as the ‘ethernet switch’ couldn’t support that protocol. You also couldn’t run various other protocols, like IPX and Apple Talk or some new protocol you’re developing and testing in your home. Abstraction layers increase development speed and encourage innovation, as you don’t need to rebuild the whole house to change a window. Now you could have ran the same ethernet switches and migrated your network in between from IPX to IPv4 to IPv6, without touching your LAN at all.

It is very common for the router-to-router links to use a protocol that doesn’t have MAC addresses.

MAC addresses appear only on IEEE type of devices 802.3 (Ethernet), 802.11 (Wifi) etc. On serial links such as HDLC, FrameRelay, ATM there are no MAC addresses

The underlying assumption with Ethernet is that the node with the destination MAC is physically on the same network as the source. There is no such assumption with IP.

To keep things simple, we can’t use MAC addresses for the simple reason that the space of these addresses is FLAT. Why do we mean by that? Knowing the MAC address doesn’t inform you about the location (routing) of that address. So we need a more hierarchical type of addresses, addresses that we can summarize. For analogy purposes imagine that every house in the world has a unique number, if I decide to send you a letter by specifying only your number, the mailing service will have no idea how to reach you (the only way is to copy that letter and send it to everyone in the world, hoping that one of these copies will reach you eventually – this is what we call flooding–) To solve this problem, we use a more hierarchical type of addressing (house number + street name + district name + town + county name). This time, the mailing service has not to know the exact location of an address, but just a part of it (and this is exactly what happens with IP: Routers have route summaries)

Let’s assume that we were able to overcome all the limitations that have been mentioned and that computers can communicate over the Internet just by their MAC addresses. And let’s say that you operated a web site that is accessed by tens of thousands of unique visitors every day. That web site lives on a server, and that server has a network adapter, and that network adapter has a MAC address. What happens if that network adapter dies, or the whole server dies? In a normal situation you just buy a new server, restore a backup of the old server, and you’re good to go. But remember, as has been mentioned, a MAC address is unique to the physical network adapter, and your new server has a new network adapter with a new MAC address. Instead of your web site being back up already, now you have to go tell those tens of thousands of unique visitors a new address (maybe you can do that via DNS, or maybe DNS doesn’t exist in our alternate universe). By the way, this is to say nothing of virtual network adapters (used in VMware, Hyper-V, etc.) whose MAC addresses are dynamically generated by the host OS (or specified by the user) and are not unique. IP addresses do all of the things the other answers describe, but they also provide a layer of abstraction so that hardware-level changes don’t have to disrupt network-level or application-level communication.

When you understand that IP-to-IP communication is really just a series of MAC-to-MAC communication taking place at each router hop, then you’ll see why both are necessary. The IP header of a packet leaving your workstation destined to an IP in a different subnet will maintain the source IP and destination IP, forgetting about NAT for the moment. Later, I will discuss what happens when the destination is within the same subnet. The Ethernet header contains your source MAC and the destination MAC of your default gateway. There’s no knowledge of the final destination MAC from your perspective. That first router will rewrite the source MAC to itself and the destination MAC to the next router hop, and so on, until the packet arrives at the last router that is directly connected to the destination subnet. To attempt a simple illustration, consider the L2/L3 headers as a packet moves from the source IP (sIP) to a destination IP (dIP) and the source and destination MACs are rewritten along the way – fs=first-source and ld=last-destination, and r1-r3 are routers:

fsMAC-r1MAC / sIP-dIP; r1MAC-r2MAC / sIP-dIP; r2MAC-r3MAC / sIP-dIP. r3MAC-ldMAC / sIP-dIP;

Any L2 switches involved will not modify the MAC addresses. Now for communication to another IP within your subnet, direct MAC communication is needed, but to get that MAC addr requires the ARP protocol that uses a broadcast in the subnet to find it. By the way, this is how your workstation gets the MAC address of your default gateway that must exist in your same subnet.

First problem with eliminating the MAC protocol requires a redesign/rewrite of the Ethernet and TCP/IP standards. Begs the question, why were they designed that way in the first place? This is just an implementation issue.

Second, IP is not the only protocol at L3 that uses MAC addresses at L2 to communicate.

Third, MAC addresses are normally tied to hardware (burned-in) addresses on NICs while the IP at the higher level are allowed to be somewhat arbitrary for flexibility.

Fourth, MACs are only locally relevant while IPs are globally relevant (not considering more recent changes with NAT’ing and private addresses that were not part of the original design)

The MAC address should uniquely identidy each computer (stricly speaking each NIC)¹

Layer-2 protocols do not care which layer-3 protocols they carry, and layer-3 protocols do not care which layer-2 protocol carries them.²

With IP we can group our computers so that all TCP/IP address that began with 10.0.x.x. are part of the engineering group, and those of 10.1.x.x. are the printers³

We can’t get rid of MAC because some protocols still rely on the MAC address. Presumably we’re not talking about things like ARP here but rather PPP etc?⁴

When you understand that IP-to-IP communication is really just a series of MAC-to-MAC communication taking place at each router hop, then you’ll see why both are necessary.⁵

However, if you need to automatically assign IP addresses there’s no way to know (for example) if a node is requesting more than one IP. Because the IP is now the only way to identify a node. ⁶

IP doesn’t assume your destination is on the same network as you ⁷

Ethernet assumes that the destination MAC is directly reachable ⁸

For MAC the space of these addresses is flat. Knowing the MAC address doesn’t inform you about the location (routing) of that address. So we need a more hierarchical type of address - IP - which we can organise into groups and then create routes to those groups. Limits the amount of info we need to keep track of.⁹