Encapsulating, shim headers, tunnelling – does it matter?

I overheard my manager today giving one of the new junior guys the run-down on basic encapsulation methods and general IP. Basically, how to TCP/IP. In explaining 802.1Q and VLAN tagging, my boss uttered the following phrase:

“…a switch encapsulates the frame with the VLAN number…”

It was at that point I ran over to his desk and put in my point (a bit of semantics, especially for a newbie) that technically, a 802.1Q tag actually modifies the Ethernet header and is more like a shim header.

An 802.1Q frame

But then GRE and IP tunnelling was brought up. And MPLS. And IPSec. And after much debate, I let the coaching continue and probably caused quite a bit of confusion for my green colleague. I’ve come to realize that I tend to fly off the handle and get a bit too far in a technical discussion that I lose those who might not have learnt or had exposure to the technology that myself and others know intimately.

Anyways, onto the whole encap-vs-tunnel-vs-shim debate. Here’s how I like to explain it and understand it myself as it applies generally:

• encapsulation distinctly divides bits on the wire. When viewing a packet in Wireshark for example, an IP packet is encapsulated in an Ethernet header and an IP header, followed by whatever transport protocol (TCP, UDP or ICMP), and then finally application data. Encapsulation forms the basic structure of data packets, with a clear division of labor. Routers inspect IP headers for destination networks. Switches inspect Ethernet headers for destination MAC addresses.
• tunnels utilize tunnel and multiple IP headers to create overlay networks riding over underlying infrastructure. GRE (with IPSec for encryption) is the most widely used tunnelling mechanism. It works great for connecting remote sites over the Internet. Internet routers only inspect the outer IP header, which is routed to the tunnel endpoint, at which point the far-end will strip the outer IP and GRE headers, and then make its own routing decisions base on the “inside” IP header. MPLS* also functions in a similar way for VPN applications.
• shim headers are the muddiest of the bunch. MPLS is often called a shim header because it inserts a small 4 byte* (32 bit) header within a data packet, which is then processed and/or inspected by MPLS-enabled routers. It also doesn’t have only one location where it could appear. In the case of pure IP L3VPNs, it’s shimmed between inner- and outer IP headers. It could also appear between disparate Layer 2 headers, in the case of Any Transport over MPLS (AToM). 802.1Q is further harder to define since it modifies existing Ethernet headers. A frame could have multiple .1Q tags in the case of dot1q tunnelling (confused yet?).

* MPLS adds an additional 20 bits per label.

And yet, after writing those short descriptions of each, it’s apparent to me that all of those terms are muddy. You can’t always define a data type as one over the other, since you’ll find numerous exceptions and special use cases (that are not so special and very widely deployed) that break any rigidly-defined “layering rules”. Smarter people than me have agreed to that fact as it relates to explaining TCP and using dated reference models such as the OSI model. The IETF has also agreed that reference models
that adhere to strict onion layers as it relates to data networks hurts more than it helps.

But I digress. The concepts of encapsulation/decapsulation and tunnelling are central concepts that all networks use. Never will you (or should you) see an end host spit out an IP packet without its data link header (mostly Ethernet these days) along with its IP header and any associated transport/application data. It’s just the way TCP/IP evolved over its development several decades ago. And it’s the best we got. Sometimes, it’s less important about terminology and semantics, and more important of the overall goal said method is trying to achieve.

If I’m grossly mistaken, be sure to let me know in the comments. I’ll try my best not to harass anyone less technical and nerdy than myself with (sometimes) unimportant details.