Everyone who studies networking memorises seven layers, and plenty of people can still recite them — Application, Presentation, Session, Transport, Network, Data Link, Physical.
The catch is that the protocol suite that model was built to describe is not used by anyone. FTAM, VTP and MHS for the upper layers, TP0 through TP4 for transport, CLNP and CONP for the network layer — those names appear in every textbook and on none of your machines.
What your machine actually runs is TCP/IP, whose defining document counts four layers.
This article is not an argument that the seven-layer model is useless. It is extremely useful as a shared vocabulary. But it will show, in real bytes, that the layers are not separated the way the diagram draws them — and that the standard knew this from the beginning.
If you have never looked, start here
Layers are not an abstraction. They are bytes stacked on top of each other, and one command shows all of them at once.
$ nc -v example.com 80That single successful connection passes through every layer together — the name example.com is resolved at the application layer, the number 80 is a transport-layer port, the resulting IP address belongs to the network layer, and the network card fills in MAC addresses at the link layer.
All of it fits in one command because no layer needs to know what the others are doing — in theory, at least.
A protocol is not software
The word protocol gets used interchangeably with the word program, but they are different things.
A protocol is an agreement about how to lay out bytes and how to respond to them, not the code that follows the agreement. Web servers from different vendors interoperate because they follow the same agreement, while sharing not a single line of code.
One agreement has to specify three things completely.
syntax which bytes sit where, how long, how to read them
semantics what each value means, and who must do what next
timing when to send, how long to wait, when to retryMiss any one of them and two ends will fail to communicate even though both can parse the bytes. The DHCP article is a clear example of timing — the values T1 and T2 live in no byte at all; they are an agreement about when to renew.
Encapsulation, counted in bytes
As data walks down from the upper layers, each layer adds its own header. That is encapsulation. I built one real frame to measure it.
bytes size section owner
0-13 14 Ethernet header layer 2
14-33 20 IP header layer 3
34-53 20 TCP header layer 4
54-69 16 payload layer 7The data anyone actually wanted to send is 16 bytes out of a 70-byte frame — three layers of headers take 54 bytes, or 77%.
That is the price of layering, and it is why protocols that send small pieces frequently — voice, games — hurt more than people expect. Every time you send 16 bytes you pay the full header price.
1994 — the standard that says it cannot be proven
The seven-layer model exists as a real document, ISO/IEC 7498-1, whose text ITU publishes identically as X.200 — and that one is a free download, unlike 802.1AX which has to be bought.
Section 6.1.3 lists the seven layers plainly.
layer 7 Application
layer 6 Presentation
layer 5 Session
layer 4 Transport
layer 3 Network
layer 2 Data Link
layer 1 PhysicalMore interesting than the list is the note in section 6.2.1, placed just before the principles it used to decide.
"NOTE - It may be difficult to prove that any particular layering selected is the best possible solution."
The standard itself says the split may not be provably the best one. That sentence is missing from nearly every textbook, leaving only the number seven, recited like a law of nature.
The principles used to decide where the lines go
The same section lists the principles, and reading them makes clear this was engineering, not discovery. Two matter most.
"b) Create a boundary at a point where the description of services can be small and the number of interactions across the boundary are minimized."
"k) create for each layer, boundaries with its upper and lower layer only."
Principle k is the rule everyone draws in diagrams — a layer talks only to the layers immediately above and below it, never across.
Hold on to that one, because three sections below will prove TCP breaks it.
The rest are equally practical — do not create so many layers that the system becomes hard to describe, separate layers when the work is manifestly different, group similar work together, and place boundaries where past experience has shown them to work.
1989 — RFC 1122 counts four
Five years before the 1994 edition of X.200, the IETF published RFC 1122, Requirements for Internet Hosts, the document that says what a machine must do to be on the internet. It counts four layers.
Application HTTP, DNS, SMTP, SSH
Transport TCP, UDP
Internet IP, ICMP, IGMP
Link Ethernet, Wi-Fi, PPPAnd it addresses OSI directly, saying the upper layers were merged.
"The application layer of the Internet suite essentially combines the functions of the top two layers -- Presentation and Application -- of the OSI reference model."
Alongside the preceding sentence: "The Internet suite does not further subdivide the application layer".
The missing layer, and the one with no home
Notice that RFC 1122 discusses merging layers 6 and 7 but never mentions layer 5 at all, because the internet stack has no separate session layer. The work OSI assigned to layer 5 is scattered between applications and TCP.
There is another piece the document openly admits does not fit.
"ICMP is a control protocol that is considered to be an integral part of IP, although it is architecturally layered upon IP, i.e., it uses IP to carry its data end-to-end just as a transport protocol like TCP or UDP does."
ICMP is part of IP and sits on top of IP at the same time — call it layer 3 or layer 4 as you like. The document chose to say it is both rather than force it into a box.
The sentence that reverses many people's understanding is in the same paragraph.
"Internet IP was the model for the OSI Connectionless Network Protocol"
CLNP, which textbooks teach as OSI's network-layer protocol, was built by taking IP as the model — not the other way round.
Proof that the layers leak, in numbers
If principle k held, TCP would be able to compute everything without knowing anything about IP. It cannot.
RFC 9293 describes the TCP checksum as covering something called a pseudo-header.
"The checksum also covers a pseudo-header (Figure 2) conceptually prefixed to the TCP header. ... Including the pseudo-header in the checksum gives the TCP connection protection against misrouted segments."
And the next sentence is the confession.
"This information is carried in IP headers and is transferred across the TCP/network interface in the arguments or results of calls by the TCP implementation on the IP layer."
The IPv4 pseudo-header is 12 bytes, and not one of them is ever transmitted. It is simply a value both ends compute with.
4 bytes source IP address taken from the IP header
4 bytes destination IP address taken from the IP header
1 byte zero
1 byte protocol number taken from the IP header
2 bytes TCP length computed, never sentChange the IP address and the TCP checksum changes
This is the experiment that settles it. I built one TCP segment, every byte identical, then computed its checksum while changing only the IP addresses, which belong to the layer below.
source destination TCP checksum
192.0.2.10 198.51.100.7 0x7654
192.0.2.10 203.0.113.9 0x6485
203.0.113.9 198.51.100.7 0xfc54
no pseudo-header 0x62b9The last line is what you get if the pseudo-header is left out entirely — one value, no matter where the segment is going.
The first three differ while the 25 bytes of TCP never move a single bit. Layer 4 cannot compute itself without values from layer 3, in direct contradiction of X.200's principle k.
And this is not a mistake; it is deliberate. RFC 9293 gives the reason: "protection against misrouted segments" — if a packet reaches the wrong machine, that machine computes a checksum that does not match and discards it. The benefit was bought by letting two layers depend on each other.
Where else it leaks
Once you know it can leak, the leaks are everywhere.
NAT, as the NAT article explains, is a layer-3 device that edits port numbers belonging to layer 4 — and having done so it must recompute the TCP checksum, because the IP addresses it just changed are in the pseudo-header.
MTU is a property of cables and network cards, the lowest layers, yet the ping article shows it breaking a TLS handshake, which is a concern of the top.
TLS has no layer number everyone agrees on. It is not layer 4 because it does not deliver anything itself, and not layer 7 because applications do not know it is there. People call it 5, or 6, or joke about "layer 4.5".
QUIC moves the entire transport job up into user programs and then sends it over UDP, which is layer 4 — a transport layer stacked on a transport layer.
The IETF's RFC 3439 has carried a section titled "Layering Considered Harmful" since 2002, explaining why.
"the operations of multiplexing and segmentation both hide vital information that lower layers may need to optimize their performance"
"layer N may need layer N-2 information (e.g., lower layer packet sizes)"
What "layer 7 firewall" actually means
Layer numbers are used to sell products more often than they are used by their definitions, and in a datasheet they usually mean this:
layer 2 switch decides from MAC addresses
layer 3 switch decides from IP addresses
layer 4 balancer decides from port numbers
layer 7 balancer decides from content, such as path or Host header
layer 7 firewall can read protocol content, not just look at portsNotice that nobody sells a layer 5 or layer 6 anything, because those two have no existence in the stack that runs. What people call "layer 7" really means "the highest layer there is" rather than the seventh from the bottom.
When it lies
"Every device implements all seven layers." No. A switch does layers 1 and 2; a router reaches layer 3. X.200 itself describes intermediate devices as relays whose forwarding functions are provided in the lower layers.
"Upper layers need not know anything about lower ones." The checksum numbers above disprove it, and MTU disproves the reverse direction.
"The OSI model is how the internet works." No. It is how a different protocol suite intended to work. That suite lost; the vocabulary survived.
"More layers is better." RFC 3439 argues the opposite: more layering adds complexity and hides information the lower layers need.
"Layer numbers in datasheets match OSI." Sometimes, sometimes not, and nobody has defined what a layer 7 firewall must actually be able to do.
Real cases from real work
Case 1 — work upward, layer by layer
Situation A user reports that a website will not load. No other information.
Command Ask one layer at a time, from the bottom, each command ruling one out.
$ ifconfig en0 | grep 'status:' layer 1, is the cable up
$ arp -an | grep 192.168.1.1 layer 2, can we see the gateway
$ ping -c2 192.168.1.1 layer 3, can we talk to it
$ nc -vz example.com 443 layer 4, is the port open
$ curl -sI https://example.com layer 7, does the app answerHow to read it The first command that fails is the layer with the problem, and you can stop there, because every layer above depends on it. This is the model's real value — it does not describe how the system works, it tells you what order to ask questions in.
What this does not prove The sequence rules out lower layers, but some faults cross layers. MTU lets the layer-3 command succeed while layer 7 fails, so working upward will report "layer 7 is broken" when the cause is at layer 2.
Case 2 — bad checksums after NAT
Situation After replacing the device doing NAT, some connections fail at random.
How to read it A NAT device has to do two things at once: change the IP addresses in the layer-3 header, and recompute the layer-4 checksum, because the addresses it just changed are inside the pseudo-header. Do the first and forget the second, and the far end silently discards the segment.
From the table above, changing only the destination address moves the checksum from 0x7654 to 0x6485 — a device that does not recompute sends the old value and the far end's arithmetic disagrees.
What this does not prove "Fails at random" fits several causes, including MTU and a full NAT table. Confirming it is a checksum problem requires capturing packets on both sides of the device and comparing them, which this article has not done.
Case 3 — explaining it to people who do not do networking
Situation You have to tell a development team why adding bandwidth did not make the application faster.
How to read it Use layers as shared vocabulary, not as physical truth. Bandwidth is a lower-layer property, while the latency the application feels comes from how many round trips the upper layers make. Saying "the problem is not on the layer you spent the money on" moves the conversation forward without arguing about numbers.
What this does not prove This is a framing, not a diagnosis. You still have to measure whether the bottleneck is round trips, CPU, or the database before concluding anything.
Case 4 — when the datasheet says "Layer 7 support"
Situation You have to choose equipment, and two vendors both claim layer 7 support.
How to read it The phrase has no shared definition, so ask what it actually supports.
can it read the Host header
can it route by path
can it terminate TLS and read inside
what protocols besides HTTP does it understandThose four questions get very different answers from products carrying the same words on the box.
What this does not prove A vendor's documentation is not the same as actual behaviour. The only thing that proves anything is testing with your own traffic.
A map still worth carrying
After a whole article pointing out where it fails to match reality, the conclusion is not to throw it away.
The model retains two real uses. The first is the order of questions, as in case 1, which genuinely saves time when something breaks. The second is a shared vocabulary that lets two people agree on which part they are discussing.
What should go is the belief that those boundaries exist in the wiring. They are lines people drew, for engineering reasons written down in a document, with a note attached saying they could not be proven best.
References
Standards
- ITU-T X.200, the same text as ISO/IEC 7498-1 of 1994 — source of the seven layers, the boundary principles, and the note quoted here. Free to download
- RFC 1122, October 1989 — the internet's four layers, and how OSI's upper layers were merged
- RFC 9293 defines the pseudo-header and why TCP needs values from the IP layer
- RFC 768, UDP, which uses the same pseudo-header
Criticism