Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

As I understand from the ISO-OSI model, MAC addresses operate on a different layer than IP addresses. This is clear to me.

I can accept that Ethernet (LAN) just does not make use of IP addresses to do communication, but uses MAC addresses. I understand that these MAC addresses cannot be used for routing outside of a LAN, as they are not hierarchically defined. I also understand that IP is the best way to do routing over the big Internet. What I am not entirely convinced of, is that MAC addresses are the best way to communicate in a LAN


My questions are the following:

  1. Couldn't Ethernet make use of IP addresses to send messages? I'm not saying it should, I'm just asking if it could have chosen to do so.
  2. As Ethernet uses MAC addresses for communication, could I create an Ethernet network where devices would not have an IP address, just a MAC address?
share|improve this question
    
By definition, an Ethernet network is a network where devices do not have IP addresses. A TCP/IP network, as you point out, is a whole other thing and IP doesn't care whether it's running over IEEE 802.3, 802.11, or 802.5. –  miken32 Feb 12 at 23:16
add comment

6 Answers

up vote 2 down vote accepted

Could Ethernet have used IP addresses instead of it's own data-link-layer addresses? Certainly not, if it wanted to be agnostic about what layer-3 protocol it used.

We design networking protocols in layers so that we can mix-and-match layers.

Ethernet was originally developed by Bob Metcalfe et alia at Xerox PARC to be Network-layer agnostic, because their goal wasn't just TCP/IP access but also for Xerox's own proprietary XNS network protocol stack/suite.

DEC (Digital Equipment Corporation) became another early adopter, using it primarily for their DECnet protocol stack/suite.

In the late 80's and early 90's there were lots of competing LAN protocol suites (all completely independent of TCP/IP) running on corporate Ethernet LANs. Besides XNS and DECnet, there was Apple's AppleTalk (EtherTalk), Novell's IPX, Banyan VINES, NetBEUI, DLC/LLC, IBM SNA, OSI/ISO, and others I've forgotten.

So, Yes, you can use Ethernet without IP. Lots of corporate networks did it in the 80's and 90's.

Because Ethernet was designed to not care about what Layer-3 (Network Layer) protocol was running on it, it was relatively easy for those corporate LANs to support mixes of various vendors' equipment, and it was relatively easy for those LANs to add IPv4 support when the Internet took off in the mid to late 90's, and it has been relatively easy for us to add IPv6 support now.

share|improve this answer
add comment

Couldn't Ethernet make use of IP addresses to send messages? I'm not saying it should, I'm just asking if it could have chosen to do so

I guess Ethernet could have used four-byte addresses like IPv4 instead of six-byte addresses. It's probably good they didn't as they'd run out of numbers by now I'd bet.

As Ethernet uses MAC addresses for communication, could I create an Ethernet network where devices would not have an IP address, just a MAC address?

You can, if you have programs that will work with MAC addresses instead of IP addresses. Of course you will be stuck on that network and cannot reach others without some hackery.

You really only need the IP layer if you plan to do routing, especially if another network may be using a different Layer 2 technology than Ethernet, such as Token Ring, which was a real possibility when most of this was developed. Who knows if another Layer 2 technology may become ubiquitous in the future, if so, IP is independent of it.

share|improve this answer
add comment
> Couldn't Ethernet make use of IP addresses to send messages? I'm not
> saying it should, I'm just asking if it could have chosen to do so.

If you are referring to Ethernet as the Network Layer, then no, it can't. The network layer requires the physical address of the network device. An IP address is an arbitrary number that is assigned to a MAC address for simplicity's sake. IP Addresses are a software solution, not a part of the network card - the hardware solution. That's why IP addresses can be easily changed, while MAC addresses are hard-coded to the card and cannot be changed (notwithstanding MAC-Address spoofing software, which even still doesn't change the address so much as it lies about what the address is)

> As Ethernet uses MAC addresses for communication, could I create an
> Ethernet network where devices would not have an IP address, just a
> MAC address?

Yes, you could, but you would not enjoy using it, as the functionality would be very limited, and not user friendly at all. There is a reason why the transport layer was implemented.

From WikiPedia, The transport layer controls the reliability of a given link through flow control, segmentation/desegmentation, and error control. Some protocols are state- and connection-oriented. This means that the transport layer can keep track of the segments and retransmit those that fail. The transport layer also provides the acknowledgement of the successful data transmission and sends the next data if no errors occurred.

So, without using the Transport layer, which nowadays means the TCP/IP protocol, you would not have the ability to ensure your data reached its destination, or have the ability for any missing pieces to automatically be reset.

share|improve this answer
    
The MAC address can certainly be changed. My (long deceased) PC used the MAC from a broken Ethernet card for years, as my ADSL provider had it tied it and charged to change it (and took a few days too). –  vonbrand Feb 13 at 2:04
add comment

As Ethernet uses MAC addresses for communication, could I create an Ethernet network where devices would not have an IP address, just a MAC address?

If you were writing all your own software from scratch, then you could certainly do this. Just have the software accept a MAC address anywhere that the normal counterpart to that program would have accepted an IP address. Use all the system calls to send raw ethernet packets rather than IP address and it will work - but it would be a huge hassle.

Generally, MAC addresses on your network do not follow any pattern. They are burned into the hardware by the manufacturer. They are long and bulky. Mine right now is C8-60-00-CA-4B-9A. The computer next to me is 00-40-F4-48-1B-88.

To have the machines be able to talk you each other, you could give each machine a hard-coded list of all the MAC addresses of all the other machines on the network so it would know where to send packets. This is a lot of error prone typing, and anytime you changed your any networking hardware you would have to go around and change all the lists to reflect the new MAC addresses.

This is a huge hassle, so you'd probably end up coming up with a way for the machines on the network to automatically discover each others' MAC addresses using broadcast packets. Then you'd give them a way to identify themselves with some meaningful address so you would have to type commands like "telnet C8-60-00-CA-4B-9A".

Turns out that this is exactly what IP does- it is a way to use meaningful numbers to address hosts on a network rather than hard coding MAC addresses. Add in DNS on top of IP and you can type command like "telnet webserver".

Couldn't Ethernet make use of IP addresses to send messages? I'm not saying it should, I'm just asking if it could have chosen to do so.

MAC addresses are 6 bytes of info and IP addresses are only 4 bytes, so you can't do any kind of 1 to 1 mapping. You need some way of finding the MAC address (to put in the packet) from an IP address (supplied by the software that wants to communicate with another host on the network).

One (hard core) way to do this would be to go into every machine on the network, and change its hardware MAC address to look like an IP address by making the top two bytes be zeros (or some other fixed number that is the same for every machine on the network) and set the bottom four bytes to the "IP address" you want them to have on the network. (Most network cards will let you go in and modify the vendor assigned MAC address)

To make this actually work, next you would also have to hack up the code in your networking stack to actually use this system. You'd basically rip out everything having to do with ARP (the method IP uses to translate IP addresses into MAC address). You'd rip out the parts that build/read IP headers. Instead, you'd replace it all with the very simple code that, given an IP packet to be sent to host at address w.x.y.z, build an ethernet frame with the DEST address set to 00-00-w-x-y-z.

You would also need a way to indicate to the receiver of a packet which protocol (UDP, TCP) it is meant for. You could probably stick this somewhere in the ethernet header by overriding an existing field. Maybe use one of the top two bytes of the source address? This would not effect the destination machines ability to receive, but could mess up some switches. You could also add the protocol to the beginning or end of the Ethernet frame and increase the payload size by one - but that is starting to smell like an IP header.

So what would all this work buy you?

First it would save you the overhead of a lookup in the ARP table on every outgoing packet. This is probably on the order of only microseconds.

You save the work of computing IP header checksums, and the memory needed to hold them. This is probably not significant on modern hardware.

You save 16 bytes in every packet on the network since there would be no IP headers. This could add up depending on the application.

The biggest gain would be that you would not have to do any ARP requests. Sending a standard IP packet to a new host triggers an ARP exchange that can take milliseconds and is unpredictable. This can be a huge gain for some applications that are very sensitive to latency and jitter.

For some very specialized applications this actually makes sense to do. I once worked a real-time system that used only broadcast UDP packets for all inter host communications for the sole reason that it avoided having those ARP sequences kick in and unpredictably add delay and jitter. I also once worked on a resource-limited embedded system that worked by sending UDP payloads inside IP packets directly (no IP header) because it saved all the complexity and memory needed to implement all the ARP and netmask and extra checksums stuff.

share|improve this answer
add comment

It's certainly possible for machines on a local network to communicate without a routing layer. You just embed message in an Ethernet frame and hope for the best. It's a bit like putting a note on a postcard and hoping the post office does its job.

You have to hope that the receiver is listening, And listen carefully for a reply message (potentially amongst a lot of other messages from other nodes). You'll be responsible for sorting out all these messages yourself.

If you want stuff like 1:1 messaging, you'll need another protocol on top of the Ethernet frames to handle all this listening for you. The Point to Point Protocol (PPP) is often used for this, over Ethernet this is is known as PPPoE. PPPoE gives you authentication and encryption, both very good ideas on a broadcast network.

But without some form of routing information you can only communicate with nodes on the local network. As soon as you start using routing information to relay messages (e.g. to the internet) you want some form of routing protocol, such as IP, or IPX. And you'll probably want transmission control (TCP) as well...

share|improve this answer
add comment

IP networks are an abstraction, a layer of indirection, that is to say that they are a virtual network - not permanently bound to any particular physical communication method or device.

An Ethernet host has one MAC address (per NIC) that uniquely identifies it globally. However, this host could simultaneously belong to many IP networks, with a different IP address for each, while always using the one MAC address.

This separation of physical and logical addressing, or virtualization of addressing, allows for certain flexibility, such as moving an IP host (e.g. a server) from one physical machine to another, with a different MAC address, but without requiring a reconfiguration of other hosts (e.g. client software).

IP, or the Internet Protocol, and Ethernet solve different problems: Ethernet provides for communication at the LAN level and only on a single LAN, it cares not what other networks the LAN may be connected to via a router. Whereas, IP is concerned with internetworking and is thus LAN-agnostic. So, could Ethernet have made use of IP addresses instead of MAC addresses? Sure, but it doesn't really gain you anything since those messages would still be restricted to the LAN.

As an answer to your second question, this kind of situation exists at different times on an Ethernet LAN that is utilising Dynamic Host Configuration Protocol (DHCP) for IP address allocation. When a new host connects to the LAN, it hasn't got an IP address, so it sends out a broadcasted Ethernet frame to all devices and awaits a reply from a DHCP server. At this point in time, the client knows neither the DHCP server's MAC address nor its IP address, hence the broadcast. On receiving the request, the server now knows the client's MAC address and so it can correctly address the reply.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.