I am confused about the way a common home router works: Shouldn’t the MAC addresses be enough to forward the information to the correct destination?

Question

From what I've understood, the way it works is something like this:

Why the necessity of associating private IP addresses to each one of the addresses connected? Shouldn’t the MAC addresses be enough to forward the information to the correct destination?

This is a specific example of what I mean:

1. I have a website hosted on a PC, connected to the router.
2. On the router, I forward the port 80 (external) to the port 80 (internal) of (instead of the local IP) the MAC address of the PC.

I know this is not how it works, the question is why it wasn't implemented like this in the first place? And yes, a frame is not a packet anyway. I just mean it for the identification purpose.

Answer 1

2. On the router, I forward the port 80 (external) to the port 80 (internal) of (instead of the local IP) the MAC address of the PC.

I know this is not how it works, the question is why it wasn't implemented like this in the first place? And yes, a frame is not a packet anyway. I just mean it for the identification purpose.

What you've described is actually very close to how IP routing works behind the scenes – when NAT or "port forwarding" is not involved, a router forwards packets by changing just their destination MAC and technically doesn't need to know the IP address of the device.

For example, in the routing table (by which I do not mean the "port forwarding" rules) you have a "gateway" or "next hop" field which is traditionally an IP address, but its only purpose is to be resolved to some kind of lower-layer address, so the routing table could perfectly well accept a MAC address directly.

But despite that, routing table entries require an IP address for various reasons. For one, using an IP address is a useful abstraction, thanks to the use of ARP (or NDP) for dynamically resolving the MAC addresses: the actual gateway can change its Ethernet interfaces, but as long as it assumes the same IP address, the same old routing configuration stays valid.

Another reason is that it's simpler to accept just one address type instead of multiple. Even a typical home gateway is not built purely with Ethernet in mind: an ADSL modem already has to deal with two entirely different MAC layers, so its routing table would need to accept two different nexthop address types.

So it's actually simpler to accept IP addresses and rely on the existing mechanisms to translate them – mechanisms such as ARP that need to be present anyway. Also, despite the additional translation, it simplifies things because it means all packets are handled the same way whether they're being delivered to the final host or to another gateway, instead of there being two different cases.

(But some networks actually use IPv6 nexthop addresses for IPv4 network routes. The origin gateway's OS simply uses NDP instead of ARP to resolve the nexthop gateway's MAC address, without any changes to the actual IPv4 packet being forwarded.)

For "port forwarding" a few of the same reasons apply, such as the ability to separate an IP address from the physical host. But the more important reason is because "port forwarding" was a much later addition to IP networking, so it's implemented in such a way that the final host doesn't need to be aware of it happening: unlike with plain routing, a "port-forwarded" packet's actual destination IP address (the one in the IP header) is translated from the router's WAN address to the internal address that you specify.

In other words, the IP address needs to be provided because the entire point of "port forwarding" as opposed to plain routing is to put the target device's IP address in the packet. The result is that the target device thinks it is indeed the destination of the "forwarded" connection and doesn't get confused by receiving a packet with the router's IP (which it would normally discard – or worse, forward back to the router).

There may have been other ways of achieving similar kinds of "sharing" an IP address between multiple devices, but they would have required changes to the devices themselves. For example, if you just directly assigned the same public IP address to all LAN hosts as well as the router – making them accept unmodified packets, with the public IP address – the devices couldn't speak to each other anymore, due to all of them having the same address. (Keep in mind that many IPv4 stacks do not allow multiple IP addresses per interface, so assigning both the public and local addresses would not be an option.) In contrast, the translation that's done

(One alternative method that does work is to assign each device a public IP address, making "port forwarding" rules unnecessary and relying purely on standard routing.)

Another related thought is that ports are not a universal concept, but belong specifically to TCP – which itself relies on IP – so although it would be technically possible to have a rule "if port 80, forward to MAC x:y:z", it logically makes much more sense to have a TCP port associated with a specific IP address (i.e. the immediate next lower layer) than with a hardware address.

---

Previous answer:

Why the necessity of associating private IP addresses to each one of the addresses connected? Shouldn’t the MAC addresses be enough to forward the information to the correct destination?

Whether it would be "enough" is not the right question. Yes, fundamentally this would be possible, but it's not really desirable – doing so would bring far more new complexity than you're expecting it would remove.

1. There are already many ways a network could be built on top of Ethernet but without IP (some of which used to be much more popular than IP was), e.g. NetBIOS, DECnet, IPX, VINES, X.25, AppleTalk are just a few protocols that were used on LANs and WANs in the past. Eventually though, practically all such networks either migrated to IP or disappeared. (X.25-based WANs or "Public Data Networks" used to be large, until they were replaced by IP-based networks.)

   Although you could still build a LAN without relying on IP, these days any LAN unavoidably needs to communicate with one major IP-based network (the Internet), so if you had a non-IP-based local network that just used MAC addresses, programs would still need to understand Internet IP addresses in addition to local MAC addresses.

   It would mean that programs and operating systems would need to deal with two different network types – MAC addresses to reach another host if it's inside the LAN and IP addresses if that host is outside. This is very similar to a current problem of using a private IP address for hosts locally and a public address when going through "port forwarding", but strictly worse.

   (To be fair, it would be a little bit like the current coexistence of IPv4 and IPv6 on modern networks, with programs needing to support both – but IPv6 has a practical need to exist and its existence aims towards unifying networks, while the hypothetical MAC-address-only network would only separate them more without any practical advantage.)

2. Even though hosts inside the same network could use just their MAC addresses to communicate, as soon as an internal host needs to send some packets to the Internet you'd still need an extra header that could hold at least the destination IP address, and the router would need to translate between the two packet types – regular IP on one side, the hypothetical "non-IP, but please deliver to an IP address" LAN protocol on the other. That's doable, but far more complex than just using the same kind of IP on both sides.

   One important point is that "private" IP addreses are a much, much later addition to IP networks – the current translation between private and public IP addresses is not a natural part of how IP works, but was largely brought by the "Common home router" years later. Before then, hosts in a LAN (if the LAN used IP) used to just have public IP addresses like anywhere else on the Internet – servers in datacenters still do – and there was no "port forwarding" needed, as you could reach any host by its own address.

Overall this would be somewhat contrary to the existence of IP in the first place – the entire goal of a network-layer protocol is to unify different kinds of networks. Currently, IP in your home LAN works exactly the same way as IP at your office or university or various public networks or the rest of the Internet.

(In a similar way, IP over Ethernet works like IP over cable works like IP over ADSL works like IP over 3G/4G, even though each of those network types has a completely different MAC-layer sometimes without even the concept of a "MAC address".)

In fact, the goal of the "upcoming" IPv6 is the complete opposite of what you're thinking about – in particular the ability to assign public addresses to every device leads to unifying the networks further by removing the "private addresses start here" NAT boundary that IPv4 LANs currently have to deal with.

(Similarly, there are continuous efforts to extend IP usage to networks that didn't use it yet, such as Thread in IoT.)

---

Side note regarding comments about MAC addresses not being routable: There already are various ways to build routed networks that only use MAC addresses; they're just not used on typical IP-based LANs because IP-layer routing is sufficient.

For example, HWMP and B.A.T.M.A.N are standard for Wi-Fi mesh networks, while SPB and TRILL in enterprise networks apply the same IS-IS routing protocol to L2 addresses as is widely used for IP routing.

(The IPX and XNS networks protocols also directly used Ethernet MAC addresses for identifying hosts, but achieved routing by having an additional "network address" prefixed to the MAC-based host address, avoiding the need to route each MAC individually. If you squint, IPv6 kind of worked the same way at first.)

Answer 2

The reason is actually really simple: So that the hosts don't have to know or care whether they are behind a NAT layer.

Consider a student with a laptop. When he carries it to the university, that laptop has to deal with public IP addresses and run software that identifies connections by IP address and port (There's no "home router" around to translate). When he carries the laptop home, it's desirable for all the same software to work. If home networks identified connections by MAC address and port instead of IP address and port, you'd need a whole different set of networking software for use at home. Imagine the pain of keeping your bookmarks and cookies synchronized between the World-Wide-Web-on-the-school-network browser program and the World-Wide-Web-on-the-home-network browser program.

By having a home router talk the same "Internet protocol" on the not-Internet side, the computers don't need two separate types of networking.

Answer 3

TCP/IP uses IP for routing traffic. It's there in the name.

If you were to use MAC addresses then you wouldn't be using TCP/IP and at that point the router would need to do even more work to take in whatever MAC based protocol is used and then forward on the requests.

It would be far more work than the simpler header modification/addition that is done by Network Address Translation (NAT).

Using TCP/IP for both internal and external networking means a far simpler network in general as the same protocol is used between machines on the same network as on the Internet and does not need smarter bridges with servers and other protocol translators.

Answer 4

The internet wasn't really designed to have "private addresses" in the first place. A device that's connected to the internet is expected to have an internet address (i.e. a public IP address). Other devices on the internet talk to it using its internet address. MAC addresses are a local-network/hop-by-hop detail that isn't available to the device on the other end of the connection.

So now suppose, for various reasons, you need to break that convention and share a public IP address among several devices, while having them function basically the same. Each device still needs/expects to have an IP address, so you give them private addresses, and you translate between the public address and private addresses on a connection-by-connection basis at the border of the network — that's NAT (network address translation).

So why can't we take your suggestion, and just take the incoming packet, look up which device its flow belongs to, slap the correct destination MAC address on it while keeping the IP address the same, and let the switch send it to the correct port? We sort of could, but that would mean that all of the internal devices would have to have their interfaces configured with the same external IP address. That's not impossible, strictly speaking, but it's enough of a pain in the butt that it doesn't gain you anything.

1. The devices on the local network wouldn't be able to talk to each other using the public address, since they all think they own the same address. If you wanted them to be able to talk to each other, you'd have to give them unique private addresses as well (and if you're doing that, why not just use the private addresses and do NAT?)

2. There will be times, in your scheme, where the router has to rewrite the port numbers on incoming/outgoing packets (for instance, to avoid a 4-tuple clash if two devices choose the same ephemeral source port for an outgoing connection to www.google.com:443, or because two devices have services listening on the same port, but you want to make them both accessible to the outside world on different ports). And even in the ordinary case it needs to be able to identify connection flows to send packets back to the correct local device. So it needs to be able to parse, track, and modify the headers of the next-level protocol (IP). These are the exact same requirements that we have with "regular" NAT routers, so again, if you're going to all that trouble, why not rewrite the address too?

3. Suppose your public IP address is dynamically assigned, as it is on most residential ISPs. Suppose your router's link goes down and comes back up, and you get a new address. You now have to reconfigure all of the devices behind the router. So you need to be able to disseminate that information to them using something like DHCP. Except DHCP as we know it is client-initiated; there isn't any way for the server to tell a client device "hey, the address you're holding a lease for isn't actually valid anymore, you'll have to get a new one". So we would need something new and different.

Basically, as icky as it may seem, the way we do things has been evolved to provide good results with the minimum of admin hassle, and it mostly succeeds at that.

Answer 5

2. On the router, I forward the port 80 (external) to the port 80 (internal) of (instead of the local IP) the MAC address of the PC.

I know this is not how it works, the question is why it wasn't implemented like this in the first place? And yes, a frame is not a packet anyway. I just mean it for the identification purpose.

The network works on layers that wrap the content of upper layers and route the data down the path to get where it goes. The internet was built on routing via IP address, and TPC is a protocol on top of that that contains the port 80. HTTP is another layer on top of that which usually uses TCP port 80.

Having equipment that operates on IP and controlling routing that way is how the internet was built. Computers nowadays have the software built-in, which wasn't always the case. To do it differently you would have to come up with your own protocols and software which would just add more complexity and weaken security. Accessing a web page involves establishing a TCP connection which itself involves IP packets sent that have nothing to do with HTTP. Actually you don't technically need TCP or even IP for HTTP, you could have a serial connection and perform HTTP requests directly over it, but what fun would that be? IP is what enables the global internet.

So say your router just sends the data on to your computer over ethernet using your MAC address. What's your computer supposed to do with this lump of data it just got? Your operating system will have to have something listening for this data which is not targeted to your IP address. Then it will have to interpret it in a way to determine what to do with it. This must match the purpose you designated this data for in your router in the first place. You're going to need some type of header for the data that the router can send telling your computer what the purpose of the data is. Congratulations, you just started developing a new protocol that nobody wants or needs!

Your computer and router already use their MAC addresses over the data link layer to send each other data over ethernet. Just most of this data is encapsulated IP datagrams that let you connect to the internet because they tell your router where the data should go.

If you're asking why not just allow you to enter a MAC address to route the incoming requests only, then I would ask why you would want to do that? The router is already built for routing IP, and it associates IP addresses with MAC addresses automatically to route the IP traffic to the proper place. Usually a network is designed around IP and you just forget the MAC address unless you want to restrict access to a particular piece of hardware. Using IP address you can re-assign addresses without changing hardware or reconfiguring your router. You can get a new network card and set it up with the old IP so you don't have to reconfigure your router. You don't have to worry about having two do both methods since IP would be about 10000 times more useful. And you have to assign an IP address anyway to put into the packet for your computer to recognize as it's own. You can have multiple IPs on your PC. You could have another router with it's own private network and just route to that router's IP if it is forwarding, or to a specific computer on the other side of that second router using its individual IP address.

Answer 6

MAC means "Media Access Control" - meaning it controls something that physically generates signals over a medium (called the PHY).

PHY examples: wired Ethernet, Wi-Fi radios on specific channels, cable modem/DOCSIS, DSL, fiber optic

Medium examples: copper, radio waves over air, optical

When you tell a PHY to talk to another MAC, the PHY can only look and see other devices with PHYs connected or listening on the same medium. This is the basis of the concept of a network.

So your Wi-Fi radio can only see other nodes that are listening on the same band and channel. Your wired Ethernet card can only see nodes that are listening on the same "wire" - which can be extended using switches. (Originally, nodes on wired networks were all physically connected to a single wire).

IP--which stands for Internetworking Protocol--a global scheme that does not care about the medium and therefore sets on top of MAC addresses.

Thus ... devices need to exist that can forward traffic that one network wants to send to others - and it will need to be connected to at least 2 networks. Those devices are called routers - and nodes that want to talk to something that is not on the same network need to send traffic to the router. The subnet mask allows nodes to know which network they are "in" (and therefore don't have to send to the router).

ISPs work the same way - your router connects to the ISP network, and the ISP has carrier-grade routers that take traffic not destined for its network and route it to other ISPs (at places called IXPs).

Answer 7

I will answer the two sub-questions given directly:

Shouldn’t the MAC addresses be enough to forward the information to the correct destination?

In a small network, Yes. Such as between Host-1, Host-2 & Host-3 in your example, it would be possibly for all hosts to know the MAC of the host they want and send data to it. In other networks with a Hub instead of a Switch you could also send Ethernet Frames to all clients on a network and set them up to just ignore data that arrives and is not addressed to them. Many Hub and Start topologies used a system like this.

Notice I said Data and Ethernet Frame, which leads on to the second part and explains why you are using Internet Protocol Addresses at all.

Why the necessity of associating private IP addresses to each one of the addresses connected?

You do not want to send Ethernet level data between clients. If you want to send IP protocol data between two clients (local or remote) then you need to provide an IP level network stack, which includes IP addresses. As The Internet is built on Internet Protocol standards a huge amount of our protocols and tools are built around this layer of networking. If you want to send TCP or UDP data, you must do so over IP (normally).

It is the ubiquity of IP networking and software that makes it necessary to use IP Addresses within a small network. It would require someone to develop and support a duplicate protocol and product to do the same job at a lower network level.

---

Side notes on NAT and Ethernet networks. NAT was a hack added to work around a lack of IP addresses before IPv6 was defined and adopted. It is now a common hack, so common that it is delaying the switch to IPv6. In the initial concept all clients and servers on The Internet were meant to have true publicly unique IP addresses.

I use some systems that do use Ethernet only traffic. These are often only connected directly to other systems or in very small networks. It allows you to start at a lower level in the network protocol stack, which is simpler for systems with limited computing or where speed is an absolute requirement. The trade off is that all the advantages given to you by IP, UDP or TCP networking are not there any many people are so use to them being present.

Answer 8

Another reason that I didn't see mentioned in the other answers is IP route aggregation. Routing tables are kept according to blocks of IP addresses, rather than individual IP addresses. Otherwise, the tables would get too large, both to maintain and to actually use. Therefore, interfaces inside the same network use IP addresses in the same subnet, and the subnet address block is announced to the outside world. So when you change networks, typically you also change IP addresses so that your address can be aggregated. (This works on a number of levels, starting from your LAN, to your local ISP, to the top tier ISP.) MAC address on the other hand are static. If we based routing on MAC addresses, routing tables would explode in size, in addition to the need of incredibly large overhead of routing protocol messaging for individual addresses.

Answer 9

The MAC address is part of layer 2 of the OSI model, in this case Ethernet.

Ethernet is not a routable protocol, so there is no concept of "default route/gateway" at layer 2

IP at layer 3 does have the distinction between local traffic and "everything else via a specific IP"

Answer 10

All other answer are long enough, here is the TLDR:

• Back in ye ol' days, the internet isn't supposed to have a "private IP address", that came after when they realized that there wouldn't be enough IPv4 to go around if the internet continue to gain popularity like this. That is why home internet access nowadays will use private IPv4 but the main router (still on the customer's premises) will have a publicly allocated IPv4 (yes, I know CGNAT exists) which will NAT every packet that came from the private IP side and translated to the public IP side (and vice-versa). The original IPv4 design is to have every internet access device have its unique and publicly reachable IP, this is currently possible with IPv6 because of its very massive amount of addresses.

• Another important thing about the IP address is that it isolates every network segment and requires a router to forward a packet to the network that is unknown to the host (outside the range of the specified netmask).

If you try to get rid of all the IP routing stuff and just straight up use MAC address for routing, all hell broke loose because now everyone will receive everyone's frames because of the nature of L2 forwarding which will flood every unknown frame to everywhere possible.

Answer 11

Why the necessity of associating private IP addresses to each one of the addresses connected?

It is not necessary. You can use only a public IP if you have a public IP range (as you get with IPv6 from your ISP), or no IP at all.

Even if you have public IPs for each device, it is still interesting to have private IPs, too, so you have addresses only accessible from inside your network (i.e. you can have a test webserver in your Raspberry PI bound to a private IP so it can only be reached from your private network), that is why IPv6 have the fe80:: link-local addresses.

Shouldn’t the MAC addresses be enough to forward the information to the correct destination?

It is, in a single network without routing.

Internet is a layered architecture, and each layer has a responsibility. We usually have:

• Physical layer: radio waves or voltage signaling in a wire actually transmitting the bits
• Link layer (usually wifi/ethernet or 4G/5G at consumer ends): handle the gritty details of error correction and retransmissions in the noisy physical environment and identification of who is talking and who is receiving (MAC addresses, in case of ethernet). I would say wifi is a sub-layer inside ethernet, because they work together as a single network.
• Routing layer (IPv4 or IPv6): handle routing across different networks with possibly different data link protocols, like between your home ethernet/wifi with your ISP cable/fiber and beyond, or subnetworks in a corporative network.
• Transport layer (usually TCP or UDP): Creates the abstraction of communication channels between applications, transparently handling messages out of order, duplicated or missing from the lower layers.
• Application layer: application specific.

Theoretically you can suppress the routing layer and implement a TCP-like protocol on top of ethernet (probably there is no RFC for that). But you lose some things:

• Obviously, you lose the ability to talk beyond your local network, as the switch only knows the devices directly linked to it.
• You lose application support, as Firefox (and pretty much every other internet application) doesn't expect MAC addresses and doesn't even know if they are over an ethernet network or something else that may not even have MAC addresses.