Nearly every answer to OSI model vs TCP/IP is a two-column diagram with tidy arrows between the columns, and every one of those diagrams is more confident than the standards it claims to summarise.
RFC 1122, Requirements for Internet Hosts — Communication Layers (R. Braden, Editor, October 1989), introduces the four-layer Internet model and organises 116 pages of binding requirements around it. Fifteen pages in, it says this about the model it has just built itself on:
“However, strict layering is an imperfect model, both for the protocol suite and for recommended implementation approaches. Protocols in different layers interact in complex and sometimes subtle ways, and particular functions often involve multiple layers. There are many design choices in an implementation, many of which involve creative ‘breaking’ of strict layering.”
The honest position is stranger than the diagram and more useful. Both models leak, they were drawn to answer different questions, and the one that describes what actually runs on your machine is the one whose own specification calls it imperfect.
The comparison table, with the column that usually gets cut
| OSI layer | Nearest home in RFC 1122’s model | Typically implemented by | Where the mapping breaks |
|---|---|---|---|
| 7 Application | Application | HTTP, SMTP, DNS, SSH | RFC 1122 folds two OSI layers into this one and says so outright |
| 6 Presentation | Application | TLS, character encodings, serialisation | TLS does presentation-layer work but runs below the application, on the transport |
| 5 Session | (nothing) | — | RFC 1122 never mentions a session layer. The word “Session” appears zero times in all 116 pages |
| 4 Transport | Transport | TCP, UDP, QUIC | TCP’s checksum reads network-layer addresses; QUIC is a transport running inside another transport |
| 3 Network | Internet | IP, ICMP | ICMP is “an integral part of IP” while being layered on IP; NAT is a layer-3 box that rewrites layer-4 fields |
| 2 Data link | Link | Ethernet, Wi-Fi, PPP | VXLAN carries layer-2 frames inside UDP — the link layer ends up above the transport layer |
| 1 Physical | (out of scope) | Copper, fibre, radio | RFC 1122 stops at “link layer or media-access layer protocol”; there is no physical layer in the model |
Every entry in that last column is sourced below, each a place where clean arrows would tell you something false. There is not even one four-layer model to compare against: the five-layer version many courses teach splits RFC 1122’s link layer back into data-link and physical, so the two pictures line up better.
The standard that defines the four-layer model calls it imperfect
That passage is not buried in an appendix or a later retrospective. It sits in RFC 1122’s introduction, right after the document explains why it is organised by layer at all — “This layerist organization was chosen for simplicity and clarity” — and immediately after it states its own modelling assumption plainly: “In describing the rules, we assume that an implementation does strictly mirror the layering of the protocols.”
An assumption, adopted for clarity, described as imperfect, by the standard that uses it. That is a working vocabulary with a disclaimer attached, and the disclaimer never survives into the diagram.
It breaks its own layering on purpose, and documents the break
RFC 1122 does not stop at conceding that layering leaks. It requires a leak. On IP options it mandates that all received options be handed upward, then explains the decision in its own discussion text:
“Passing all received IP options to the transport layer is a deliberate ‘violation of strict layering’ that is designed to ease the introduction of new transport-relevant IP options in the future.”
Network-layer data is passed to the transport layer, by requirement, because a clean boundary would have made the protocol harder to extend later. The scare quotes around “violation” are the IETF’s own.
The word “Session” appears zero times
Search all 116 pages of RFC 1122 for the string “Session” and you get nothing. The document is explicit about the top of the stack — “The application layer of the Internet suite essentially combines the functions of the top two layers — Presentation and Application — of the OSI reference model” — and has nothing at all to say about layer 5.
That is the cleanest disproof of the tidy table. Layers 6 and 7 collapse into one by the IETF’s own account, and layer 5 has no counterpart. Any diagram drawing a horizontal line from OSI’s session layer to something on the Internet side invented that line.
The two models were drawn to answer different questions
The seven-layer model is a reference model. ITU-T publishes it as Recommendation X.200 — Information technology – Open Systems Interconnection – Basic Reference Model: The basic model — with the in-force edition listed by ITU’s own catalogue as X.200 (07/94), superseding an 11/88 edition (checked 8 September 2026); ISO publishes the same model as ISO 7498. Its job is to define service boundaries in advance, so independently written standards can slot into named positions.
RFC 1122’s four layers are a documentation convenience, applied after the fact to protocols that already ran. They were not designed so that new protocols could be assigned a layer. They were chosen because they made a requirements document easier to read.
So “which model is correct?” is the wrong question. One is a taxonomy written before the artifacts; the other is a filing system built around them. The influence also ran both ways, which the versus framing erases — RFC 1122 notes in passing that “Internet IP was the model for the OSI Connectionless Network Protocol.”
A layering violation sits inside the 1981 TCP specification
The most consequential layering break in networking is not a middlebox hack. It is in RFC 793, the September 1981 TCP specification. TCP’s checksum is not computed over the TCP segment alone; it also covers a 96-bit pseudo-header, and RFC 793 spells out the contents:
“This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. This gives the TCP protection against misrouted segments.”
Source address, destination address and protocol number are network-layer fields. A transport-layer checksum is specified to reach one layer down and include them. The engineering reason is sound — a segment delivered to the wrong host fails the check — but under strict layering, TCP should not be able to know those values exist.
Forty-one years on, it is bigger rather than smaller
RFC 793 was obsoleted by RFC 9293 (STD 7, August 2022). The pseudo-header survived the rewrite and grew: “The pseudo-header is 96 bits for IPv4 and 320 bits for IPv6.” Four decades of revision, and the transport layer now reaches further into the network layer than it did in 1981.
Four questions the seven-layer diagram cannot answer
Where does TLS live?
Both answers are correct and they contradict each other. Over TCP, TLS has its own record layer above the transport — RFC 9001 describes records “individually cryptographically protected and then transmitted over a reliable transport (typically TCP), which provides sequencing and guaranteed delivery.” Presentation-layer work, above layer 4.
Over QUIC, the same protocol sits somewhere else. RFC 9001 again:
“…instead of carrying TLS records over QUIC (as with TCP), TLS handshake and alert messages are carried directly over the QUIC transport, which takes over the responsibilities of the TLS record layer.”
The transport carries TLS’s handshake in its own CRYPTO frames, and TLS supplies the keys the transport uses to protect its packets. Neither is above the other. TLS’s layer number is not a property of TLS; it is a property of what happens to be underneath it.
Where does QUIC live?
QUIC does transport work — reliability, flow control, congestion control — and RFC 9000 states its substrate plainly: “QUIC packets are carried in UDP datagrams.” The transport layer therefore contains a transport running inside another transport, in userspace, at a position the model has no number for. The reason is ossification, and that story belongs to QUIC’s own design rather than to this argument.
Where does a VPN live?
Encapsulation destroys the idea that a protocol has a layer. RFC 7348 does not even hide it; the title is “Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks” — layer-2 frames carried inside UDP, which is layer 4, which rides layer 3. IPsec does the same thing one layer up: RFC 4301 defines a tunnel mode in which “AH and ESP are applied to tunneled IP packets.” IP inside IP.
Once a packet is encapsulated, the layer number stops being an attribute of the protocol and becomes a coordinate: which stack, at which depth. The model has one axis. Real traffic needs two.
Where does a NAT box live?
A NAT is nominally a layer-3 device and cannot do its job while staying there, because of the pseudo-header above. Rewriting an IP address invalidates the TCP checksum computed over it, so RFC 3022 devotes a section to checksum adjustment across “IP, TCP, UDP and ICMP headers.”
The section after it is worse. For ICMP error messages, RFC 3022 requires the translator to modify “the IP address of the IP header embedded within the payload of ICMP-Error message”, that embedded header’s checksum, the ICMP checksum, and — in NAPT setups — the TCP or UDP port number inside the embedded packet. A layer-3 box rewriting a transport port buried inside another packet’s payload. No diagram survives that.
Using a vocabulary you do not believe
None of this makes the seven-layer model useless. It makes it a vocabulary rather than a specification, and vocabularies are allowed to be lossy.
The OSI model is genuinely good at naming a concern. “This is a presentation problem, not an application problem” is a sentence worth being able to say, and RFC 1122’s four layers give you no word for it. It is the better teaching vocabulary while being the worse description — a strange thing to be true, and true anyway.
The four-layer model is genuinely good at describing the machine. A link layer, an IP layer, TCP and UDP, and applications: that is what a packet capture shows and what a kernel implements.
The failure mode runs both ways. Insisting a protocol has one true layer produces confident nonsense about TLS and QUIC. Dismissing the models because they leak throws away the only shared vocabulary engineers have for arguing about where a function belongs. The working posture is RFC 1122’s own — use the layering, expect to break it, and document the break as deliberate when you do.
That is also why this comparison is worth doing carefully rather than tidily. The hub article this one belongs to argues that TCP/IP won its protocol war without the losers being obviously worse, and the layer diagram is exactly where that history gets flattened into a scoreboard.
❓ Frequently Asked Questions
Is the OSI model obsolete? As a description of deployed protocols it never described the Internet stack in the first place. As vocabulary it is very much alive: “layer 3” and “layer 7” are load-bearing terms in firewall, load-balancer and switch documentation, and nothing has replaced them. Obsolete is the wrong axis.
Which model should I learn? Both, for different jobs. RFC 1122’s four layers let you reason about what a packet capture is showing you. OSI’s seven give you words for concerns the four-layer model does not name. The third thing to learn is that neither describes a real system, which is what stops you making confident wrong claims in a design review.
What layer is TLS at? There is no single answer, and RFC 9001 is why. Over TCP, TLS runs its own record layer above the transport. Over QUIC, the transport takes over the record layer’s responsibilities and carries TLS handshake messages directly. Same protocol, two positions, decided by the substrate.
Does the TCP/IP model have four layers or five? RFC 1122 defines four — application, transport, internet, link — and has no physical layer, stopping at the “link layer or media-access layer protocol.” The five-layer version common in teaching splits that link layer into data-link and physical so the picture lines up with OSI. Both are in circulation, which is itself evidence that the layer count is a pedagogical choice rather than a fact about the stack.
If nothing implements OSI’s session layer, why is it in the model? The reference model was written to define service boundaries in advance, not to summarise existing protocols, so it includes positions no widely deployed Internet protocol ever filled. Session functions do exist in practice, but they are rebuilt inside individual protocols — TLS session tickets, QUIC connection IDs, HTTP cookies — rather than provided once by a shared layer.
If both models leak, why do certifications still test the seven layers? Because an approximate shared vocabulary is still worth testing, and because most of what exams ask about — layer 2 versus layer 3 forwarding, a layer 7 proxy — is genuinely used that way in industry. The upgrade is not to reject the model but to hold it the way RFC 1122 does: an imperfect organising principle you break deliberately, and document when you do.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, this site earns a small commission at no extra cost to you.
On this particular question the free primary material genuinely beats the books, and saying so is more useful than padding a list. Every claim in this article came out of documents that are free, permanent, plain text, and shorter than the blog posts that summarise them.
Read RFC 1122 first, and read the introduction rather than the requirements. RFC 1122 is 116 pages of host requirements, but Section 1.1.3 — two pages — is the entire honest answer to this question: the four layers, the sentence calling strict layering an imperfect model, and the statement that the Internet application layer absorbs OSI’s top two. Then search the file for “Session” and find nothing. That search takes ten seconds and settles the argument better than any diagram.
Then read the layering violation in its original form. RFC 793 (September 1981) defines the TCP pseudo-header; RFC 9293 (STD 7, August 2022) is the current specification and shows the same violation, larger. Reading the two checksum sections side by side is a short, concrete lesson in what survives forty-one years of revision.
For the awkward cases, RFC 9001 Section 3 explains in one paragraph why TLS has no fixed layer, RFC 3022 Sections 4.2 and 4.3 show exactly how far a NAT must reach into a payload, and RFC 7348 puts layer 2 inside layer 4 in its own title. RFC 3234 is the best short account of what middleboxes did to the model, and RFC 3439 contains a section titled “Layering Considered Harmful” written by two network operators.
Free and better than a chapter: open a packet capture of an HTTPS request and try to assign each header a layer number. The exercise fails in an instructive place, and the place it fails is this article’s argument.
Three books, if you want the long form
- TCP/IP Illustrated, Volume 1: The Protocols, 2nd edition — Kevin R. Fall and W. Richard Stevens, Addison-Wesley. Still the reference for what the headers actually contain, and the place to go after RFC 793 for the checksum and the pseudo-header.
- Patterns in Network Architecture: A Return to Fundamentals — John Day, Prentice Hall. The most sustained argument in print that the layer models are wrong in ways that matter, written by someone who worked on OSI. Contrarian, occasionally infuriating, and the only book here that takes the modelling question itself as its subject. ⚠️ ASIN UNVERIFIED
- Computer Networks, current edition — Andrew S. Tanenbaum, Nick Feamster and David J. Wetherall, Pearson. Worth reading specifically because it teaches the five-layer hybrid model and explains why it does: a textbook openly negotiating between the two maps rather than pretending one of them fits. ⚠️ ASIN UNVERIFIED