Why do we need MAC addresses?(immibis.com)
immibis.com
Why do we need MAC addresses?
https://www.immibis.com/blog/why-mac-address
72 comments
> The MAC address is meaningful only for a single link
This isn't entirely true. In ye-olden days, Ethernet was a proper bus architecture, where you would have many devices talking on a single line.
As networks got larger, we wanted to have more devices than we could get on a single cable, so we introduced cheap booster hubs that would physically connect multiple cables. Since these hubs didn't have any fancy switching logic, it continued to look to devices like everyone was on a single bus (which they basically were).
Eventually, compute became cheaper, and the limitations of having a massive bus more apparent, so we started replacing some of the Ethernet hubs with Ethernet switches to reduce contention. It still looks as if everyone is on a single bus; but now a node only sees traffic involving a node on its side of the nearest switch. Notably, these switches were drop in replacements for hubs, so they did not rewrite MAC addresses.
Nowadays, actual Ethernet hubs are a dying breed (although I still keep one lying around to avoid buying an expensive managed switch with a monitor port). Almost every Ethernet cable you run into today is a genuine point-to-point connection connecting two specific nodes, and carrying only the data that needs to be sent between those nodes.
Now that modern Ethernet is a full featured packet switched protocol, it has to deal with all the routing issues that come with that. This led to the introduction of the Spanning Tree Protocol, to allow Ethernet switches to construct Ethernet routing tables. Notably, nothing inside of these Ethernet networks replaces MAC addresses. When computer A sends to computer B on the same Ethernet network, the destination MAC address A uses is B's actual MAC address, regardless of how many switches are between them.
This isn't entirely true. In ye-olden days, Ethernet was a proper bus architecture, where you would have many devices talking on a single line.
As networks got larger, we wanted to have more devices than we could get on a single cable, so we introduced cheap booster hubs that would physically connect multiple cables. Since these hubs didn't have any fancy switching logic, it continued to look to devices like everyone was on a single bus (which they basically were).
Eventually, compute became cheaper, and the limitations of having a massive bus more apparent, so we started replacing some of the Ethernet hubs with Ethernet switches to reduce contention. It still looks as if everyone is on a single bus; but now a node only sees traffic involving a node on its side of the nearest switch. Notably, these switches were drop in replacements for hubs, so they did not rewrite MAC addresses.
Nowadays, actual Ethernet hubs are a dying breed (although I still keep one lying around to avoid buying an expensive managed switch with a monitor port). Almost every Ethernet cable you run into today is a genuine point-to-point connection connecting two specific nodes, and carrying only the data that needs to be sent between those nodes.
Now that modern Ethernet is a full featured packet switched protocol, it has to deal with all the routing issues that come with that. This led to the introduction of the Spanning Tree Protocol, to allow Ethernet switches to construct Ethernet routing tables. Notably, nothing inside of these Ethernet networks replaces MAC addresses. When computer A sends to computer B on the same Ethernet network, the destination MAC address A uses is B's actual MAC address, regardless of how many switches are between them.
The really awesome part about Ethernet hubs was that if you knew what you were doing, you could get everything on the bus delivered to your device. Fun fact, in the 90s, most every college dorm had one hub per building (or if you were at MIT, one huge network for all of them).
Since most everything ran over plain text, you'd be surprised what you could learn when you aggregated all AOL IMs and ICQ messages in one interface...
Since most everything ran over plain text, you'd be surprised what you could learn when you aggregated all AOL IMs and ICQ messages in one interface...
Gentlemen don't read each other's packets ;)
Of course not. But I was 18 and certainly not a gentleman. Teenagers are morons. :)
I would never do such a thing now of course.
I would never do such a thing now of course.
Now that everything is https, I don't think that you could.
Why do you think everything is https now? :)
Go on, I'm interested...
It's because Firesheep made it easy to do exactly that
Oh, of course. I thought you were implying that not everything is https today.
Could be done on switched networks too through arp spoofing
It's a lot harder though, because you can only target a single IP at a time and many switches have preventative measures built in. Back in the day the hub would conveniently send all the packets on the network to you and all you had to do was listen.
not really and not true, back in the day ettercap automated arp cache poisoning a LAN which lets you sniff more than 1 target since they map the gateway with the attackers mac address, switches might protect against this now but even in the early 2000's it was very effective (not that I would ever do it)
Someone recently did a YouTube demonstration of an Ethernet bridge: https://www.youtube.com/watch?v=Hvqv9QcTcfA (skip to 15:22). It's a large, $8000 (in 1986), 10kg device with a 68000 processor that connects to exactly two ethernet busses via AUI ports. It even speaks an earlier variant of STP. It remembers a certain number of MAC addresses on each bus, and when it sees a packet on one bus addressed to a device on the other bus, or a broadcast, it stores it and sends it when the other bus is free.
The idea of a two-port switch sounds silly until you realize there can be 30 devices on each port.
The idea of a two-port switch sounds silly until you realize there can be 30 devices on each port.
Oh, that thing. The next step up was the DEC DELNI, the same thing but with about 8 ports. Had one of those sitting under a raised floor.
The main purpose of bridges like that was to overcome the electrical limitations of coax Ethernet. Cable losses, transceiver losses, and length limitations meant that beyond some length, you needed a power booster.
The main purpose of bridges like that was to overcome the electrical limitations of coax Ethernet. Cable losses, transceiver losses, and length limitations meant that beyond some length, you needed a power booster.
>so we started replacing some of the Ethernet hubs with Ethernet switches to reduce contention.
I just remembered having to answer questions about Ethernet hubs vs switches many years ago. To me, ethernet hubs are entirely theoretical, I don't think I've ever seen one in the wild.
I just remembered having to answer questions about Ethernet hubs vs switches many years ago. To me, ethernet hubs are entirely theoretical, I don't think I've ever seen one in the wild.
You weren’t missing much. They sucked. Switches were an improvement in every way.
Don’t get me started on the ugly detour that was ATM, for when Bellheads wanted to build out the Internet like a phone switch, and when no one could agree on optimal cell sizes and they compromised on 53 bytes to piss off everyone equally.
(Also, to have been a fly on the while when you worked out that whole congestion thing.)
(Also, to have been a fly on the while when you worked out that whole congestion thing.)
It took over two decades for things to settle. The telco people had ATM and Frame Relay and DSL voice and a Bell Labs thing called Datakit. They were trying to get deterministic voice, so voice over packets wouldn't suck. What we ended up with is voice with lag, jitter, echo, dropout, and over-compression. So nobody talks on the phone much now.
Give a fellow a little warning before conjuring those names!
When it became clear that packet switching was going to win out, did the telcos ever try to emulate circuits with UDP flows or similar? It seems like IP over switched circuits would look a lot like virtual switched circuits over IP, if you squint just right.
When it became clear that packet switching was going to win out, did the telcos ever try to emulate circuits with UDP flows or similar? It seems like IP over switched circuits would look a lot like virtual switched circuits over IP, if you squint just right.
I remember working on a federal contract back in the early 2000s where there was a camp of ATM folks against us who were pushing Metro Ethernet and MPLS. The TL;DR of it was the ATM guys won, spent millions of dollars, only for us to come in and replace it all a year after it was supposed to have been done in the first place.
Cisco sure made some good money on failed ATM projects back then!
Cisco sure made some good money on failed ATM projects back then!
I witnessed the same. Yeah, charging twice to build out each link is a pretty good profit model.
Something seems a bit off about this article. "Because Ethernet came first" is the real answer; and it being a local network technology, was not readily scaled beyond that, despite the MAC address space being 64k times larger than the IPv4 address space. A key point worth noting about the IP address space, which enabled this crucial scaling to global networks, is its hierarchical structure. MAC addresses are assigned to hardware interfaces, independent of their location, while IP addresses are assigned hierarchically much like numbers in the telephone system, allowing for relatively easy routing at a global scale.
A typical packet found on a typical network has a structure like this
IPv6? That's... not really "typical", yet. IMHO even packets with 802.1q tags are going to be more commonly found and "typical" than IPv6.
A typical packet found on a typical network has a structure like this
IPv6? That's... not really "typical", yet. IMHO even packets with 802.1q tags are going to be more commonly found and "typical" than IPv6.
Google says nearly half their global traffic is IPv6 today, as is a vast chunk of mobile traffic. It’s pretty typical lately.
Is that including their internal traffic? I would expect that the traffic they control runs way more ipv6 than what comes in from customers.
Looks like that’s just for customers: https://www.google.com/intl/en/ipv6/statistics.html
Very interesting. Thanks.
Good to see adoption is happening, even if it’s slow.
Good to see adoption is happening, even if it’s slow.
It's mostly because mobile networks can't get the size of address blocks they'd need to give every customer an IP address. They all run CGNAT, but that's a pain too. Both Google and Apple require your apps to work on IPv6-only networks IIRC, or they won't be approved for the app stores. Fun fact: Your website loads faster on cellphones if it supports IPv6, because the CGNAT gateway detour adds measurable latency.
I see the Ethernet coming first answer in another comment too. Just to be clear, many protocols came before IPv4 that aren't in play. It's not because it came first, it's because they're layered. Why need an IP if you have a port number? Why need a port number if you have a url?. As also mentioned in a comment, there's IPv4 over not just Ethernet. So I agree with your comment, but a bit of pedantry goes a long way
Ethernet did not come first. IP was running over non-Ethernet links long before there was Ethernet.
Ethernet can't scale like IP because it's a non-hierarchical address structure.
Ethernet can't scale like IP because it's a non-hierarchical address structure.
The answer to this question is wrong:
> Why don't we just make IP networks without Ethernet?
The article implies that we need MACs, and of course we don't, and lots of protocols exist that don't use ethernet framing. SLIP and PPP only speak IPv4, for example.
Also the real reason behind the "why" is more boring than the blog implies. Ethernet predates IP. It's a simple (almost the simplest possible) protocol for a bunch of hosts to share a single network without running into trouble talking to each other. And it decided on a hardware-unique "MAC" as its way of doing addressing.
It was simple, so it was cheap. So everyone built out cheap ethernet hardware. And when it arrived, everyone wanted to run IP on their cheap ethernets.
> Why don't we just make IP networks without Ethernet?
The article implies that we need MACs, and of course we don't, and lots of protocols exist that don't use ethernet framing. SLIP and PPP only speak IPv4, for example.
Also the real reason behind the "why" is more boring than the blog implies. Ethernet predates IP. It's a simple (almost the simplest possible) protocol for a bunch of hosts to share a single network without running into trouble talking to each other. And it decided on a hardware-unique "MAC" as its way of doing addressing.
It was simple, so it was cheap. So everyone built out cheap ethernet hardware. And when it arrived, everyone wanted to run IP on their cheap ethernets.
IP and routing is actually the interesting question. Somehow we need to get these IP packets to right place. And this opens up question how would it be done with just IP packets? You would at least need some extra protocol over IP as IP itself really does not have idea where the next jump on the route is...
Routing on Internet scale is messy question really. And then moving physical bits over any medium is also somewhat complicated always. So ethernet and MACs works relatively well for helping in both...
Still, it is somewhat nice thought exercise to think how you would do without it.
Routing on Internet scale is messy question really. And then moving physical bits over any medium is also somewhat complicated always. So ethernet and MACs works relatively well for helping in both...
Still, it is somewhat nice thought exercise to think how you would do without it.
Media Access Control (MAC) address is the method to control access to the physical transmission medium. A switch doesn't care about your upper layers (IP, TCP, etc.) but won't find your host without a MAC address. That's why MACs are called hardware address and work on the local link only, from the port on your cool network interface to the other end of the cable or radio signal.
Why do we need MAC addresses?
So we can spoof them, of course.
So we can spoof them, of course.
At university, our network required antivirus to be installed, which really sucked and destroyed the performance of your machine. So my laptop became an Xbox, which was exempt from antivirus policies :)
Network people: Do we even need MAC addresses anymore? Can we not just have a UUID that the device generates?
They seem to get more abuse over time i.e. MACs are how a car is uniquely identified and authenticated with fast charging CCS networks for Autocharge.
They seem to get more abuse over time i.e. MACs are how a car is uniquely identified and authenticated with fast charging CCS networks for Autocharge.
> Can we not just have a UUID that the device generates?
They kinda are already, your phone probably uses a random MAC address for each network it connects to.
They kinda are already, your phone probably uses a random MAC address for each network it connects to.
We don't NEED it, just like we don't need to use IP. But the standards are just easy to use. Feel free to develop your own L2 protocol. I remember using SLIP to make a point to point over FM radio, and there was no addressing used, just IP.
Article is pretty spot on. We need MAC addresses for local area networking. Nothing is stopping you from using any physical layer outside of your home network. But of course everything client these days uses Ethernet based technology.
When a router is used you still do see the MAC address but only of the directly connected next hop/device. If another router, then it would change the headers appropriately.
A router is connected to multiple networks and for networks running on Ethernet, yes, each device on those networks has a MAC address its interface connected to it.
The headers of IP packets wouldn’t be affected by MAC addresses, Ethernet packets carry IP packets as their payload and would have their own headers as appropriate.
A router’s job is essentially to “pass on” or relay IP packets based on its routing tables, they are what connect networks together.
The headers of IP packets wouldn’t be affected by MAC addresses, Ethernet packets carry IP packets as their payload and would have their own headers as appropriate.
A router’s job is essentially to “pass on” or relay IP packets based on its routing tables, they are what connect networks together.
> The correct answer is simple: The Internet doesn't use MAC addresses, and Internet packets don't have MAC addresses. At all.
> A typical packet found on a typical network has a structure like this:
> Destination MAC address
> Source MAC address
> A typical packet found on a typical network has a structure like this:
> Destination MAC address
> Source MAC address
IP packets and Ethernet frames are separate animals. Ethernet doesn’t know IP, except for a flag saying “interpret my payload as an IP packet”. It doesn’t have src or dst IP addresses. And an IP packet doesn’t know about its physical transport. It doesn’t have src or dst MAC addresses.
You can put other things than IP packets inside Ethernet frames. You can put IP packets into non-Ethernet carriers.
The short version is that small LANs route frames by MAC addresses and don’t know about IP addresses, and the Internet cares only about IP addresses and not MAC addresses.
You can put other things than IP packets inside Ethernet frames. You can put IP packets into non-Ethernet carriers.
The short version is that small LANs route frames by MAC addresses and don’t know about IP addresses, and the Internet cares only about IP addresses and not MAC addresses.
Yes I am aware, I was just pointing out that they are claiming that MAC addresses exist in "packets" (not frames) while simultaneously saying they don't.
Ah, got it. Yeah, they could’ve been clearer about that. I still call them packets sometimes when I’m talking with someone in person and we both know what we mean, but I try to be a stickler when writing docs.
That jumped out at me too and seemed an "LLM-ism", but the article looks entirely human-generated.
The fact the wrong ethertype is used in the packet at the beginning (0x88dd, IPv6 instead of 0x0800 for IPv4) made me think of an AI generated article too.
It is consistent with the rest of the fields for IPv6, but normally one would write IPv6 explicitly, and implicitly IP to mean IPv4.
a bit disappointed this only points to ethernet as its answer. it does help to understand why ethernet requires addressing versus some others that do not.
Pretty much everything that isn’t point to point, like PPP or a VPN, can carry IP traffic directly without needing to care about MACs (because they’re only talking to one other interface). Anything that routes physical packets around needs the equivalent of a MAC address.
Ethernet is already a complete network that doesn't care about the fact you're running IP on top of it. Being a complete network includes having a way to address the computers on it. There are ways to transmit data point to point without addressing but they're not really "networks" until they have that.
Ethernet was designed to be the cheapest way to network multiple machines together. Everything was connected to a single long loop of coax with "vampire taps" that literally bit into the coax to connect multiple machines. So there's no central machine routing packets, instead each machine needs to decide whether or not a packet is intended for it. So the packets have to have a unique[0] destination address, as well as a source address so you know who to reply to.
Notably, none of this implies IP. IP was the expensive DARPA project that the military was building out. Ethernet is just "I am machine X, I want to talk to machine Y, here's some data". It just so happens that Ethernet was very popular, and people wanted to route IP over Ethernet. But you could route all sorts of other protocols over Ethernet as well and it would more or less work. So now we need two different classes of addressing: one for just the local network, and one for the IP network running on top of it.
And to make matters even worse, we don't use Ethernet in its original configuration anymore. First we replaced the loop of coax and vampire taps with 8P8C wire and passive hubs, then switches got cheap enough that we stopped making hubs. Ethernet framing also wound up being used for Wi-Fi, except like 99% of all Wi-Fi connections are in Infrastructure mode running IP anyway.
If Ethernet had been built to run IP exclusively, we wouldn't need Ethernet's header or MAC addresses at all. It would just need to encode IP packets and their boundaries. Even IPv6 wouldn't need a separate header as IP has its own version field.
[0] MAC addresses are supposed to be unique, but let's just say it's "LAN-scoped" and leave it at that.
Notably, none of this implies IP. IP was the expensive DARPA project that the military was building out. Ethernet is just "I am machine X, I want to talk to machine Y, here's some data". It just so happens that Ethernet was very popular, and people wanted to route IP over Ethernet. But you could route all sorts of other protocols over Ethernet as well and it would more or less work. So now we need two different classes of addressing: one for just the local network, and one for the IP network running on top of it.
And to make matters even worse, we don't use Ethernet in its original configuration anymore. First we replaced the loop of coax and vampire taps with 8P8C wire and passive hubs, then switches got cheap enough that we stopped making hubs. Ethernet framing also wound up being used for Wi-Fi, except like 99% of all Wi-Fi connections are in Infrastructure mode running IP anyway.
If Ethernet had been built to run IP exclusively, we wouldn't need Ethernet's header or MAC addresses at all. It would just need to encode IP packets and their boundaries. Even IPv6 wouldn't need a separate header as IP has its own version field.
[0] MAC addresses are supposed to be unique, but let's just say it's "LAN-scoped" and leave it at that.
"The Internet doesn't use MAC addresses, and Internet packets don't have MAC addresses" is a wrong assumption. What's an "Internet packet"? Without MACs there's no networking. Without networking there's no Internet.
Layer 3 IP packets indeed do not contain MAC addresses, but layer 2 (ethernet or otherwise) frames might.
the internet predates MAC addresses - it was originally running over serial modem connections.
True. In the Second Edition the Preface mentioned that "Finally, the number of UNIX installations has grown to 10" and some of those systems were connected mostly via telephone lines.
The article refers to a "typical packet found on a typical network" then describes an Ethernet frame, so the author clearly refers to MACs in an Ethernet setup.
MAC is part of the Ethernet standard. The clue of why is needed for is in the name "access control". Without MAC there's no Ethernet. Without Ethernet there's no Internet.
Wait ...there are other networking standards!
The article refers to a "typical packet found on a typical network" then describes an Ethernet frame, so the author clearly refers to MACs in an Ethernet setup.
MAC is part of the Ethernet standard. The clue of why is needed for is in the name "access control". Without MAC there's no Ethernet. Without Ethernet there's no Internet.
Wait ...there are other networking standards!
Are any of them typical?
A MAC address is needed to bootstrap IP, even if non-routable - and because we don't want to bootstrap MAC addresses, we just assign them statically. From the very beginning (oversimplifying a bit, but I digress), a MAC has really just been the key in a hashed map from MAC to switch port.
You _could_ design a system where MAC addresses were always randomized, but this technology evolved at a time where processing power and the bandwidth of your switches likely might have struggled with the additional load.
If we were designing a system from scratch it would probably make sense for everything to have hierarchical, switch-local identities that were cheap to allocate and check and put a bit more extra routing storage in the switch chips to efficiently route these.
You _could_ design a system where MAC addresses were always randomized, but this technology evolved at a time where processing power and the bandwidth of your switches likely might have struggled with the additional load.
If we were designing a system from scratch it would probably make sense for everything to have hierarchical, switch-local identities that were cheap to allocate and check and put a bit more extra routing storage in the switch chips to efficiently route these.
In the very beginning of ethernet there were no switches - you just had a bunch of transceivers connected to a length of coax cable.
Every NIC on the wire saw every packet; the destination mac address indicated whether the packet was interesting enough to each node to be worth putting a copy in host memory and bothering the CPU to look at.
Every NIC on the wire saw every packet; the destination mac address indicated whether the packet was interesting enough to each node to be worth putting a copy in host memory and bothering the CPU to look at.
For the young’uns amongst us: switches use to be an expensive luxury. Most small LANs used cheap hubs at the edges, where every inbound Ethernet frame was sprayed out to all the other ports.
They commonly had “collision” lights, and they used ‘em.
They commonly had “collision” lights, and they used ‘em.
Yup. Was going to say the same thing. I remember my first encounter with a switched network bent my brain. What, I have to give everything an address? Where'd this 192.168 come from? Networking used to be so easy! Anyway, we all learned and adapted.
> a MAC has really just been the key in a hashed map from MAC to switch port.
Until you consider broadcast/multicast traffic.
Until you consider broadcast/multicast traffic.
> A MAC address is needed to bootstrap IP...
This is fundamentally incorrect. IPv4 for LAN, sure - but "bootstrap" it is not.
There's plenty of L2 that have no MAC: PPP, ATM, Frame Relay, etc. Also, MACs aren't needed for IPv6. ND works without MAC in v6.
And, finally... There's no MAC for loopbacks.
This is fundamentally incorrect. IPv4 for LAN, sure - but "bootstrap" it is not.
There's plenty of L2 that have no MAC: PPP, ATM, Frame Relay, etc. Also, MACs aren't needed for IPv6. ND works without MAC in v6.
And, finally... There's no MAC for loopbacks.
None of those l2 protocols can traverse a wan without an encapsulation layer which always requires an address or link to the physical layer.
Sure they can - a WAN is the same as a LAN, but bigger. However, that comes with different tradeoffs, in particular the need to reduce bandwidth by using less chatty protocols. But you can absolutely rent a fiber between two buildings in the same city and run Ethernet on it.
The Xerox plan for Ethernet was to use XNS, with a 32-bit network ID and a 48-bit MAC. Routers only had to know how to find a network ID, and once the packet hit the correct destination network, the MAC address routed it to the destination.
Early on, there was a thing for "multi-protocol routers", that forwarded XNS, DECnet, IP, and a few other things such as Parc Universal Protocol, PUP. Cisco was once big on this, because Cisco came out of Stanford, which had a few of everything and tried to interconnect them. In the 1990s, most of those branded protocols died out, although as late as Windows 2000, Microsoft still supported TP4, a bad idea from circuit-oriented telco people. There was a telco approach to networking, where you dialed up a reliable circuit to your destination, transmitted what you had to send, and later got a bill for the call. This, fortunately, lost out to IP.
(I had real doubts about pure datagram long distance networks. We didn't know how to deal with congestion in the middle of a pure datagram network. We still don't, but cheap fiber saved us from having to.)