Fifth and sixth layers. After the cable, the MAC addresses, the IP, and TCP, logically, we should be talking about the session layer, followed by the presentation layer.

Except that we have to be honest: these two layers are practically nonexistent.

Not in the sense that they’re useless—but in the sense that, in the network you manage every day, no one implements them as such. There is no “Layer 6 protocol” the way there is a Layer 3 (IP) or Layer 4 (TCP). These are two layers that the OSI model envisaged, that theory describes in detail, and that reality has simply absorbed elsewhere.

Hence the title. This article doesn’t explain how to configure layers 5 and 6—you don’t configure anything. It explains what they were supposed to do, why they disappeared, and where their functions went. This is an article about network theory, not hands-on configuration. But it’s exactly the kind of nuance that separates those who have memorized OSI from those who have understood it.

> The Essentials in 30 Seconds > > - OSI has 7 layers. TCP/IP, which is actually in use, has 4. OSI layers 5 and 6 have no equivalent in TCP/IP—they’re merged into “application.” > - Layer 5 (session): supposed to manage the establishment, maintenance, and resumption of a connection. In practice, these functions reside in TCP or within the application. > - Layer 6 (presentation): intended to manage data formatting—encoding, encryption, compression. In practice: TLS, UTF-8, JSON, gzip… all handled by the application. > - You never configure Layer 5 or 6. There is no service to start, no port to open. > - Knowing that they are theoretical prevents you from looking for them where they aren’t—and from giving the wrong answer in an interview.

The Initial Misunderstanding: OSI Is Not TCP/IP

To understand why two entire layers are “phantom” layers, we need to address a confusion that has persisted since the beginning of this series and that it’s time to clear up once and for all.

There are two models, and they don’t have the same number of layers.

The OSI model (7 layers) is a theoretical model, designed by the ISO in the 1980s as a universal reference. It breaks down communication into seven distinct, clearly separated functions. It is a descriptive model: it is used for discussion, teaching, and identifying problems.

The TCP/IP model (4 layers) is the actual model—the one that powers the Internet. It arose from implementation, not theory. It merges several OSI layers because, in practice, no one needed to separate them.

Here is the correspondence, and it explains everything:

OSI (theory) TCP/IP (reality)
7 — Application
6 — Presentation Application
5 — Session
4 — Transport Transport
3 — Network Internet
2 — Link
1 — Physical Network Access

Look at the right-hand column: OSI layers 5, 6, and 7 are consolidated into a single “Application” layer in TCP/IP. This is not an oversight. It’s an engineering observation: in the real world, what falls under the session, data link, and application layers is handled in the same place—within the program itself.

This is exactly the same phenomenon we saw at the very bottom of the stack, where OSI separates the physical (1) and data link (2) layers while TCP/IP merges them into “network access.” The real-world model simplifies at both ends.

Layer 5 — Session: the dialogue

What it’s supposed to do, in theory.

The session layer manages the conversation between two applications: opening it, maintaining it, closing it properly, and, above all, synchronizing it. Textbooks assign three functions to it:

  • Establishing and terminating the session—deciding when the dialogue begins and when it ends.
  • The dialogue—managing who speaks when (half-duplex, full-duplex).
  • Synchronization — setting checkpoints during a long transfer, so as not to have to start over from scratch in the event of an interruption. The classic example: a 2 GB transfer that is interrupted at 1.9 GB resumes at the last checkpoint rather than from zero.

What Actually Happens.

None of these functions have a dedicated protocol in TCP/IP. They exist—but elsewhere:

  • Session establishment and termination are handled by the three-way handshake and TCP close. The “session” in the networking sense is the TCP connection itself. It operates at Layer 4.
  • Resuming from a checkpoint, when supported, is handled by the application. An rsync command that resumes an interrupted transfer, an HTTP download with a Range header that picks up where it left off, a backup client that resumes its job: these are examples of application code, not a network layer.

The few protocols often cited as “Layer 5” in training—NetBIOS, RPC, PPTP, sockets—are either programming interfaces, legacy protocols, or things that straddle multiple layers without truly belonging to any one. None of them is “the session layer protocol” in the same way that IP is the network layer protocol.

In a nutshell: Layer 5 describes a real function—managing a dialogue—but this function is handled by TCP below and by the application above. There is nothing in between.

Layer 6 — Presentation: Format

What it’s supposed to do, in theory.

The presentation layer deals with the form of the data, regardless of its meaning. Its role: to ensure that what one machine sends, the other can read, even if they don’t have the same internal architecture. Three tasks:

  • Character encoding — agreeing on how to represent text (ASCII, UTF-8, EBCDIC in the past).
  • Encryption — transforming the data so that a third party cannot read it.
  • Compression — reducing the volume of data before transmission.

On paper, this is the “translator” layer: it takes data in the application’s internal format and converts it into a neutral, transportable format that is understood by both sides.

What Actually Happens.

These three functions are ubiquitous in modern networks—but none of them constitutes a layer. All are handled by the application or by libraries it calls:

  • Encoding: UTF-8 has become the de facto standard. When your browser reads Content-Type: text/html; charset=utf-8, this is a “presentation layer” negotiation… handled by HTTP, an application protocol.
  • Encryption: This is TLS, and it’s the most interesting case—we’ll come back to it in a moment, because it deserves a section all its own.
  • Compression: gzip, brotli, deflate. When a web server returns Content-Encoding: gzip, it’s performing “Layer 6” work… via an HTTP header, which is at Layer 7.

The data formats themselves—JSON, XML, JPEG, ASCII, UTF-8—are the examples we use to illustrate Layer 6. But note: these are formats, not network protocols. No one “configures the presentation layer.” You choose a format in your code, and that’s it.

The TLS Case: The Most Visible “Phantom Layer”

If there’s one place where Layer 6 seems to come back to life, it’s TLS (Transport Layer Security), the encryption behind the little padlock in HTTPS. It’s the perfect example, because it shows just how blurry the layered model becomes as soon as you step away from theory.

TLS clearly performs a presentation layer function: it encrypts data (Task #2 of Layer 6). But look at where it actually sits:

  • Its name says “Transport Layer Security”—it presents itself as Layer 4;
  • it relies on TCP (Layer 4), so it’s above it;
  • it serves HTTP (Layer 7), so it’s below it;
  • it encrypts data, which is a function of Layer 6.

So, which layer is TLS? There is no single correct answer to this question, and that is precisely the point. It is generally placed “between layers 4 and 7,” or it is said to occupy “layers 5 and 6” all by itself. The truth is that TLS does not adhere to the OSI model because the OSI model was never intended to be implemented—only to describe.

TLS is living proof that layers 5 and 6 correspond to real functions (managing a secure session, encrypting content) which, in the real world, are handled by a component that refuses to fit into a box. It’s a phantom layer because it does the work of layers 5 and 6 without actually being one of them.

Why It Matters Anyway

At this point, you might ask: if these layers don’t exist in practice, why bother? There are three very concrete reasons.

So you don’t look for them where they aren’t. A beginner debugging an encryption problem will “look for Layer 6.” There isn’t one. The problem lies in TLS, in the web server configuration, or in a certificate—all application-level issues. Knowing that Layer 6 is a myth means looking in the right place from the start. For exams and interviews. The question “At which layer does TLS reside?” is a classic—and it’s a trap. The wrong answer is to blurt out a number with confidence. The correct answer is to explain that TLS spans multiple layers, that it performs a presentation-layer function (encryption) while relying on the transport layer, and that the OSI model reveals its limitations here. This answer immediately distinguishes those who have truly understood the concept from those who have merely memorized the facts.

To understand the true architecture. The modern network does not have seven neatly organized layers. It has a highly structured lower part of the stack (layers 1 through 4, where each protocol has its clear place) and a blurred upper part of the stack (5 through 7), where everything happens within the application and its libraries. Accepting this ambiguity means stopping trying to force a theoretical model onto a reality that doesn’t conform to it.

Common Mistakes

  • Looking for a “Layer 5 or 6 protocol” like those found in Layers 3 or 4. There aren’t any. These are functions, not protocols.
  • Trying to configure the presentation layer. There is nothing to configure: no service, no port. Encryption is configured in TLS; encoding is handled by the application.
  • Answering “Layer 6” without qualification when asked about TLS. TLS spans multiple layers; making a categorical statement is the trap.
  • Confusing format and protocol. JSON, UTF-8, and JPEG are data formats, not network protocols. They illustrate Layer 6 without being implementations of it.
  • Believing that OSI describes reality. OSI describes; TCP/IP implements. The two do not overlap at the top.

Key Takeaways

  1. OSI has 7 layers; TCP/IP has 4. Layers 5, 6, and 7 of OSI are merged into the single “Application” layer of TCP/IP. This isn’t a simplification; it’s a reflection of real-world engineering.
  2. Layer 5 (session) describes a real function—managing a dialogue—which is handled in practice by TCP below and the application above. There is no dedicated protocol.
  3. Layer 6 (Presentation) describes three very real functions—encoding, encryption, and compression—all of which are handled today by the application (UTF-8, TLS, gzip).
  4. You never configure these layers. No services, no ports. If you’re looking to “tweak Layer 6 ,” you’re looking in the wrong place.
  5. TLS is the epitome of a “phantom layer”: it does the work of layers 5 and 6 without fitting into any specific category. It’s the best demonstration that the OSI model describes without implementing.
  6. The top of the stack is fuzzy, and that’s normal. The bottom of the stack is structured; the top is application-oriented. Accepting this fuzziness means you’ve understood the model rather than just reciting it.

Layers 5 and 6 were the ghosts of the model. Layer 7, on the other hand, is the exact opposite: it’s the most vibrant, the richest—the one where HTTP, DNS, TLS, and DHCP reside—everything you interact with every day. It’s the top floor, and the most populated.

Next article.