Welcome to Let’s Talk Tech with Deep Core Data, DCD’s video based informative blog. In this episode of How the Internet Works, Dr. Deep Core (John Brewer) takes us back in time to discover how Ethernet connections streamlined internet connectivity, and why they remain the fastest, securest connections in any office space.

Hello, and welcome to Let’s Talk Tech with Deep Core Data. I’m John Brewer, the owner and Founder at Deep Core…where we’re using education to help businesses make the right tech choices. In this series we’re discussing, at a technical level, How the Internet Works.

Once upon a time, there was a dark time in the kingdom of computers. Computers were chained together by the evil of wired connections. Long distance communications were spoiled by the limitations of repurposed phone cords. Other realms were downtrodden by the woes of incompatibility. For many years, the users of the digital realm waited for a hero.

Some time in the early 1980’s, there were a wide variety of physical networking standards for sending information from machine to machine. It was a bit of a mess. Today we still have a lot of standards for sending information wirelessly, but when it comes to high-speed, hard-lined communication, there’s really only one game left in town: the long-lived Ethernet.

Developed in the 1970s at the famous Xerox Parc Laboratories, ethernet has outlived other standards to become part of everyday computing. It’s the phone cable looking thing that plugs into computers, as least for now, but the end of cabled connections is a story for another time.

In past episodes, we talked about how IP packets are routed over long distances, but we skipped over how those packets actually move from one physical machine to another. In many offices, wired connections still provide a faster, more secure way of moving data. So how does your computer send a packet to the switch, and how does the switch send it on to your coworker’s computer?

Ethernet also uses its own addressing scheme known as the Media Access Control, or MAC Address. MAC Addresses need to be unique to every device on the local network, and although they are usually set at the factory, most network cards today allow you to change a device’s MAC Address to fit your network needs. For those of you with more interest about the ethernet frame, you can look up the IEEE 802.3 specification.

So while a protocol like IP has the packet, Ethernet has the frame. Now, the frame is a much more simpler form of communication; where the IP packets have thirteen fields, the Ethernet Frame has only six. They are the six-byte “Destination”, the six-byte “Source”, an optional 4-byte “Tag”, the 2-byte “EtherType”, or length of the packet, the actual payload of the packet, and the 4-byte “checksum”.

Now, the source and destination addresses seem pretty self-explanatory, but there’s an important note about them: the sender address is always the original sender of the the frame, not the most recent router, like you would see in IPv4.

As an IP packet moves across the network, for example, it would be moved from frame to frame each time a router redirects it, but each of those frames will keep the source from the last frame.  

The practical upshot is that if an IP packet travels across the whole world, passes through dozens of routers, the frame it arrives in at its destination will still have the source MAC address of the machine that originally sent it.

For a moment, we’re going to skip ahead here to the EtherType/Size field. To make sense of this field, we need to know a little about the history of the Ethernet specification.

Early on, this field was just the size; it told the receiving device how many bytes to read off the link before it reached the end of the packet.  Very simple. Data is data.

In the 1980’s, when DeLorean’s and time travel were the norm, Ethernet II Framing also came down the road. The major change with Ethernet II was identifying the content of the frame. By allowing the infrastructure to know what kind of information it was sending, we enabled all kinds of new efficiencies.

Since there were only five fields at the time, and all of them were essential, the new protocol was like a parasite, usurping the size field for its own encoding. Why the size field? Let’s investigate.

The original 802.3 standard specified the maximum length of an Ethernet Frame’s payload to be 1500 bytes, but the two-byte size field could contain numbers up to 65,535 bytes. To maintain backward compatibility with all the Ethernet I hardware already out there, the Ethernet II specification declared that all the codes for these new, content-identifying numbers had to be higher than 1535 (the additional 35 bytes are to deal with possible ambiguities over padding around the frame.)

So if the EtherType/Size field is 1500 or less, that’s just the length of the data in the frame.  

If it’s 1535 or higher, it’s a code telling the receiving device what kind of information is in that frame. If the number is between 1500 and 1535, then it triggers the apocalypse. Those codes aren’t in use.

For example, the EtherType code for IPv4 in hexadecimal 0800; for IPv6, 86DD; for ARP, 0806, and so on.

I know there are some people at home all but jumping out of their chairs now asking how the receiving device could possibly know the length of the payload from a static code. Does every switch in the world need to know where in an IPv4 payload to find its length?  What kind of sloppy coding is this anyway?

But no, there is numerical trickery here.

You see, I left out one key element: Ethernet II cheats.

At the end of the frame, there is an “end-of-stream” signal.  With old 10-BASE-T networks, it was a specific waveform on the line, with 100-BASE-T networks it’s a special End of Stream delimiter payload. Every physical layer, or type of cable, that carries Ethernet II has it. It’s basically a sound, and it tells the receiving device that it’s reached the end of a frame.

There’s one other strange thing about the Ethernet frame: there’s an optional field in the middle. So the nagging question of all time: what is that field used for?

To explain, we’re going to have to go back to the EtherType field. You see, one of the EtherType content codes just says “I am a tag, and the real Ethertype is behind me.” If hexadecimal 9100 appears in the Ethertype field, that actually says the two bytes after me are a VLAN identifier, and the two bytes after that are the real Ethertype code. Pretty neat, huh? But what’s the point?

VLAN stands for Virtual LANs, and that’s a topic for another video altogether. In general, it’s a method for allowing multiple different networks to share hardware without sharing traffic.

Moving on, next we come to the Payload. The payload is the actual data the frame is transporting; the IPv4 datagram, the ARP packet, or whatever. The interesting thing about the payload is unlike anything else we’ve seen so far, it actually has a minimum length.  

For regular frames, the payload’s minimum size is 46 bytes. The minimum is 42 bytes if it’s tagged. Why is there a minimum here?  

The short answer is that long ago, when Ethernet originated, engineers needed to make sure the frames were big enough that we could reliably detect collisions on the network. It’s less of an issue today, but the specification remains, in the rare cases where someone plugs an antiquated piece of hardware into a network.

And at last, we come to the final four bytes, the cyclic redundancy check, or CRC. The CRC is a computed value that, when combined with the rest of the frame, always yields this particular output [GRAPHIC: 0xC704DD7B]. If you plug your frame into the CRC function, and you don’t get this number out, you know that the frame was corrupted in transit and needs to be resent.

So that’s the basic Ethernet Frame, or how devices on the local area network talk to each other.

Having defeated the digital foes of incompatibility, our hero fades into the annals of time. For now, the network is a better, faster place. But one day, not long from now, a new hero will rise to replace the old.

I hope you enjoyed this episode of “How the Internet Works.” If you liked what you saw, please subscribe to our channel. And if you have questions or suggestions for future videos, please leave a comment below.

I’m John Brewer for Deep Core Data. Thanks for watching.

Interested in learning more? Check out our other videos on how the internet works: the IPv4 Packet, Fragmentation, Subnet Routing, and Address Resolution Protocol.