There's no doubt the vast majority of Ethernet frames are transporting IP packets. I know there are various other protocols that can be transported over Ethernet as well, but those can be transported over IP as well.

With modern Ethernet networks being full-duplex, Ethernet has effectively turned into a point-to-point interconnect between an endpoint and a switch, which switches the packet based on the MAC destination. L3 switches do the same thing but also perform some IP routing.

Since we use Ethernet mostly only as a means to transport IP, is there any reason to have that extra layer of L2 overhead? Why not just route packets based on the destination IP? I suppose that would be breaking the OSI model, to some extent, in that L2 would cease to exist.

Imagine a link layer technology that was designed only to transport IP, and didn't have any specific L2 functionality or header of its own. Switches and routers would continue to exist like today: switches would be "basic routers" (just like L3 switches are) and mostly only take fixed routes and a default route. Switching flow: is there a route in place for this destination? Stick it in that interface's queue. If not, stick it in the default route's interface's queue.

Is there any compelling argument for keeping things the way they are?

Since we use Ethernet mostly only as a means to transport IP, is there any reason to have that extra layer of L2 overhead?

Naming a few common protocols or features that require L2 overhead such as Ethernet:

  • Spanning-Tree (requires 802.2 LLC)
  • ISIS (requires 802.2 LLC)
  • Vlans
  • ARP (which is not just for ethernet)
  • Choosing between IPv4 and IPv6
  • IEEE 802.11 Wifi (which shares many basic functions with 802.3 Ethernet, but is fundamentally a different protocol)

Ethernet has effectively turned into a point-to-point interconnect between an endpoint and a switch, which switches the packet based on the MAC destination. Is there any compelling argument for keeping things the way they are?

You are over-simplifying the argument to suggest that Ethernet is only for addressing and point-to-point. IEEE 802.3 also covers the physical layer: various forms of copper and fiber media, encoding on the wire, error recovery, line conditioning, and so on. If you add all these functions directly on IPv4, you have now duplicated many functions inside Ethernet and what have you really saved? This also ignores the monumental standardization and engineering effort to build these directly into IPv4 and IPv6. My brain hurts to think how this would work at a practical level anyway.

In the end, the argument is economics. The entire planet has engineered servers, switches, operating systems, etc. Around the assumption of a link-layer between IP and the signal encoding on the wire. Ethernet does a lot for us, and it's extremely cheap because it's now become the de facto interconnect technology for most computers on the planet. Replacing Ethernet is somewhat akin to replacing the US Congress as a governing body. It may not be perfect, but it's inconceivable to do anything else at this point.

  • 1
    Your argument over that certain protocols require Ethernet is backwards. Those protocols were invented for Ethernet. If we don't have Ethernet L2 domains we don't need STP. ARP is used to map IP information to Ethernet and again, if we don't have Ethernet we would not need it. Choosing between IPv4 and IPv6 on a link would be easy if we make the rather reasonable assumption that we only have IP on the link, as the IP version is the first 4 bits of both IPv4 and IPv6 headers. ISIS runs 802.2 LLC over Ethernet networks but does obviously not over other mediums like SDH or serial links. – kll Oct 29 '15 at 13:15
  • 1
    You've misunderstood the point. I'm answering "Since we use Ethernet mostly only as a means to transport IP, is there any reason to have that extra layer of L2 overhead?" in 2013. Yes, some of these things were invented for ethernet, but that's not the question that was asked. The OP wants to know why we still need the overhead of ethernet frames. – Mike Pennington Oct 31 '15 at 4:33
  • 2
    I think you're not reading the whole answer. The last paragraph makes the reason for still using ethernet encap very clear. If you are this confident in your ideas, go ahead and start a company that implements IP directly on the wire. But if it's a public company, I'll be shorting it on the stock market from the day it IPOs. – Mike Pennington Nov 1 '15 at 9:18
  • 2
    @kll, "Those protocols were invented for Ethernet." If you are going to nitpick old posts, please get your facts straight. "If we don't have Ethernet L2 domains we don't need STP." STP is part of IEEE 802.1; Ethernet is part of IEEE 802.3. Just like VLANs, STP was designed independent of Ethernet and as such could be used in any multiple bridge environment to prevent L2 loops. "ARP is used to map IP information to Ethernet and again, if we don't have Ethernet we would not need it." Again, wrong. ARP also existed for L2 technologies, Token Ring being one of them. – YLearn Nov 4 '15 at 5:16
  • 2
    @kll, I up voted both answers. They both address different parts of the question posed by the user, Yes, ytti does address part of the question you quoted from the OP better. However in addition to your quote, there are "Why do we still use Ethernet?" and "is there any reason to have that extra layer of L2 overhead?" and "Is there any compelling argument for keeping things the way they are?" All of which are not addressed well by ytti's answer. Further, the OP equating end point to switch as "point-to-point" is flawed at best for a variety of reasons not touched on. – YLearn Nov 5 '15 at 5:56

It's very good question.

I don't think we'll get rid of Ethernet, as multi-access links are still going to be needed indefinitely.

However, much of the core network really has no use at all for DMAC/SMAC, so there certainly should be 'point-to-point' variant of Ethernet with much shorter frame. Instead of current 18B (DMAC+SMAC+Type+FCS), you could do with 6B (Type+FCS).
This point-to-point variant of ethernet would nicely offset the overhead needed in core (MPLS labels, VLAN tags) so customer/edge frame-size would more closely follow core frame-size. It would also remove need for ARP and ND, reducing risks and simplifying the core.
Technically, there is no reason why you couldn't entirely drop L2 part of ethernet, but you're going to need its L1 part, as IP itself has no specification how to code it to any wire. So you could run L1 ethernet with L2 payload (IP) directly on top of it.

I'm personally convinced that when the time comes that we'll specify new ethernet header to use EUI64 instead of EUI48, people will want a point-to-point flavor of that L2 protocol. I don't believe it will be 'null L2', as at least Frame Check Sequence (FCS) and payload-type (IP? MPLS? Ethernet?) seem desirable.

  • Very good thoughts. I also had the thoughts about being able to remove ARP - I suppose that's just another bonus. – rfb Sep 7 '13 at 8:54

I'll answer this with an absurd question... Why don't we still use ARCnet? Or Token Ring?

There are (were, and will be) numerous layer-2 technologies. For "desktop" systems, ethernet won. Why do we still use it... the simplest answer is because it works; the technology is simple, cheap, robust, and plentiful. (read: proven technology) For the record, there are PCI "desktop" ATM cards -- I've not seen one in years, and I've never seen one actually in use.

What you suggest is merely a new layer-2 technology. I wish you the best of luck getting the world to adopt it.

[Ok, token-ring still exists, but it's exceeding rare.]

Is there any compelling argument for keeping things the way they are?

Good question, some thoughts.

  1. Compatibility is often more important than efficiency.
  2. Most network builders (outside some very high security applications) don't want to statically assign devices to ports. So some kind of system for automatically locating devices is needed.
  3. It is useful to have an identifier that identifies a specific piece of hardware wherever it happens to be plugged in.
  4. For IPv4 at least we probably don't want to waste an IPv4 address on every switch port.

It would probably be possible to design a link protocol that solved 2 through 4 while having a lower encapsulation overhead than Ethernet framing or possibly no Encapsulation overhead at all but it would not be a trivial case of saying "just use IP".

And then you still have to convince people about 1, lots of pain in adopting a new standard for a relatively small gain.

Cranking up the speeds while keeping the framing format the same is the path of least resistance. So it's what happens.

P2P Ethernet is possible. But

  • It require full L3 Network (each link use fixed IP addressing)
  • MAC addresses overhead is sensible for small packets and in L2 tunnels.
  • About link performance. If link not speed enough, don't make new protocol and software, just do same simple things in 10X faster. It is how Ethernet won.
  • About L2 tunnels. In L3 only network, L2 tunnels meaningless.
  • Unification is good thing.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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