Why do we need IP addresses to communicate within the local network segment?
Because MAC addresses are only usable across the local network segment, we use IP addresses to communicate with other segments via routers. Meanwhile, for local targets, ARP is used to translate IPs into MAC addresses and the MAC addresses are used from then on in the conversation.
This leaves me to wonder why we use IP addresses at all on the local network. Given a scenario where all systems are in the same subnet, it would seem that IP addresses are then superfluous since the systems are only really using MAC addresses to route communications between each other.
Could computers actually do without IP addresses entirely, if they do not need to communicate outside the local network segment? Why don't they?
IP addresses are explicitly not designed to be bound by hardware where as MAC addresses are. MAC addresses can be changed temporarily most of the time but each device is supposed to have a globally unique factory assigned MAC address.
Furthermore, MAC is specific to Ethernet, and while it is now the defacto Layer 2 encapsulation method, it wasn't always the case and you never know if something better will come along in the future.
Quite simply, it is a lot easier and very little overhead to do the same thing for people inside your network segment as outside your network segment.
Some other possible reasons
- You may want to use IP's to help remember what something is (the router ends with
.1kind of stuff) - You may want to run two networks on one segment that do not talk to each other (you can do that with IP via Subnets)
- MAC addresses are not easy to remember.
In short, no... you don't need IP addresses to connect machines in the same network. There are several examples of protocols like this like: IPX or Banyan protocols.
The problem with using hardware-addresses is best described like this:
Imagine for a moment that computers are people in a room... (everyone is glued to 1 spot and can't move around) If Bob wants to talk to Suzy... he shouts out "Hey Suzy"... and Suzy responds... and a conversation ensues. Great right? Sure... on a small scale this works quite well and is actually used regularly in some networking protocols between two (or a few) devices. (Many high I/O protocols use non IP protocols because they're much "simpler" and finely tuned for the task.) The Internet (as we know it today) is not just 2... or a few people talking directly to each other. The internet is literally BILLIONS of devices. If they were all placed into the same "room" (network-segment)... Imagine what would happen if Bob wanted to talk to Suzy. Bob would yell "Hey Suzy!"... and Bob's voice would be lost in the crowd. (Building a room to fit BILLIONS of people is equally ridiculous.)
For this reason, networks are segmented into "smaller rooms" which allow people who are in the same segment (room) to talk directly to each others, but people outside the room you need some sort of router to pass messages from one room to the next room. But the vast number of rooms means you need some sort of addressing scheme so the various routers in the middle know how to get a message from Bob to Suzy. With the IP protocol, they assign a subnet to each "room", and the routers are told how to pass a message from one room to the next. For example, if Bob's address is 1.1.1.1, and Suzy's address 2.2.2.2, and Bob's subnet is 1.1.1.0/24 (meaning the first 3 bytes of his address must match for it to be in his room), Bob needs to pass his message to the router so it can be passed along to Suzy's "room*. Bob knows his router is 1.1.1.2, so he passes the message to the router, and the router passes it along to other routers in the middle until the message is passed to Suzy's router at 2.2.2.1, which hands the message directly to Suzy... and Suzy can send the reply back to Bob in the same way.
Computers in the same subnet actually do communicate directly with each other using the MAC address. It actually starts by sending out an ARP request (ARP = Address Resolution Protocol) which means it shouts out "Who has the address X.X.X.X?"... and whoever has that address replies and from that point on, they continue to talk to each other directly.
(I can continue this analogy and explain a great deal more of how the Internet works if you're really interested.)
In theory, there's no reason that we couldn't just use Ethernet MAC addresses to communicate on a LAN segment.
In fact, as someone mentioned upthread, that's pretty much the way it works: your laptop sends out an ARP request saying "I'm 11:22:33:aa:bb:cc, my IP is 10.10.10.20 - who has 10.10.10.10?", your NAS responds to say "I'm x.x.x.10 and my MAC address is aa:bb:cc:11:22:33!". Subsequent packets between your laptop and the NAS will have the appropriate MAC address in the Ethernet frame header.
So, why do I say 'in theory'?
Well, in practise, the Ethernet standard provides a mechanism by which devices can locate each other on a network segment; this is useful, because it means that devices that aren't participating in a network conversation don't have to listen to it and that switches can track what physical port each device is connected to. It reduces the amount of network chatter on a segment and increases the overall throughput of the network.
Unfortunately, there's a lot of great stuff that's provided by the TCP/IP stack that Ethernet doesn't provide, and with good reason. These missing features would need to be implemented by the developers of each networked application, which is a hell of a lot of work to go to when every modern operating system has, at the very least, a TCP/IPv4 stack and probably also has an IPv6 one.
There's also the simple fact that simple network often don't stay simple - sooner or later you're going to want to connect your LAN to the internet or to another LAN; IP is routable, MAC addresses aren't.