I could be wrong but authentication happens at layer 7 as well, no? It’s either baked into the FTP protocol itself or it leverages another layer 7 protocol like LDAP.
IMO layer 5 is strictly about managing the actual TCP AND UDP sessions (assuming TCP/IP of course) on the host. As in closing stale sessions, trying to re open an interrupted session, etc. I don’t see any room in that layer to be fussed with things like user auth. That’s gotta be layer 7.
Layer 6 functions might get handled by the application itself in layer 7 too. For example HTTP has aspects of presentation layer functionality built in to it. FTP is likely the same. ASCII encoding happens within the application.
First, one must understand that layers are are a conceptual model, not necessarily something you can touch and feel and point at. In the case of TCP/IP applications, the upper layers are all handled by the same code and as such it becomes difficult to draw fixed lines and say "this function is layer 6 and this function is layer 7".
It is a model explaining a concept. It is useful as a tool for explaining a way of thinking. Don't overthink how to apply it to actual applications/code/functions/lines of code.
In the case of FTP, the presentation layer is involved in getting credentials from the user. Then said credentials are used at the protocol level. It quickly becomes messy to separate the two.
Also, layers 8 to 10 are what most of us are fighting on a daily basis. :-/
I would disagree that the upper layers are all handled by the same code. Layer 5 is OS-layer stuff. Layer 7 is obviously application layer stuff.
I also need to disagree that layer 6 is where user creds are gathered. Layer 6 is really focused on data translation, standardization and formatting between layer 5 and 7 and again is largely incorporated into application protocols themselves at layer 7.
Not an expert, so YMMV. I think a better example of Layer 5 would be authentication of hosts via ssh key exchange and cypher agreement. But... I would jump 5 and 6 altogether as long as they get out with a \*VERY\* clear understanding of the rest. :)
I can also think about RPC for layer 5.
I think Layer 5 spirit is not well presented in FTP, because the session is stablished in the app layer, which is 7.
This is what I also had doubts about. If authentication and encoding of ftp are sort of baked in to ftp then it is hard to say those two function at different layers.
1Layer 1 - Physical Layer: At this layer, the actual physical connection between the devices is established. This could be Ethernet cables, Wi-Fi signals, or any other physical medium. In the case of FTP, this could involve the physical cables connecting the client and server to the network.
Layer 2 - Data Link Layer: This layer deals with the addressing of devices on the network and the transmission of data frames. In the case of FTP, this could involve the Ethernet frames used to transmit FTP commands and data between the client and server.
Layer 3 - Network Layer: This layer is responsible for routing packets between different networks. In the case of FTP, this could involve the IP packets used to route FTP traffic between the client and server across different networks.
Layer 4 - Transport Layer: This layer ensures reliable data transfer between the client and server. In the case of FTP, this could involve the TCP protocol used to establish connections, manage flow control, and ensure data integrity during file transfers.
Layer 5 - Session Layer: This layer establishes, manages, and terminates connections between the client and server. In the case of FTP, this could involve the establishment of a session between the client and server, including authentication using a username and password.
Layer 6 - Presentation Layer: This layer is responsible for translating, encrypting, or compressing data as needed. In the case of FTP, the choice between ASCII and binary transfer modes could be considered an example of presentation layer functionality. ASCII mode is used for transferring text files, while binary mode is used for transferring non-text files like images or executables.
Layer 7 - Application Layer: This layer provides the interface between the user and the network services. In the case of FTP, the user interacts with the FTP client application to initiate file transfers and manage files on the server.
And yes, ASCII/Binary transfer method as an example for Layer 6 (Presentation Layer) and using a username and password for authentication as an example for Layer 5 (Session Layer). These practical examples help in understanding how the OSI model applies to real-world network protocols like FTP.
In the end, “practically” you would need to use ftp over a CLNS connection 🙄. Layers 5-7 really shouldnt be considered to most packet based networks. Understand the OSI model but ultimately little “Practically” uses it.
> I am ok with layers 1-4
Good. Stop there.
The osi model doesn't map to reality. We don't design protocols based on osi.
Once you realize you're in tcp or udp its usefulness is fully over.
---
Still don't believe me? Go read up on how ssh works and then try to map sftp to the osi model.
You're going to want to include the ssh channel AND the ftp session negotiation in layer 5 but you're actually in layer 7 of ssh before you can send any ftp commands.
The encryption is obvious in ssh but the same problem happens with the data stream in the wrapped ftp data stream.
And then you move up to layer 7 and have to decide if "channels" in ssh are actually the session control or if they are wrapped under the larger ssh connection.
---
Just learn the three layer model and treat everything about it as "application bs"
Wait for it, FTP as a service has different modes… oh no! And it has different handling requirements for each, oh bugger! and let’s not cover all the options… holy crap!
In practice the model breaks down pretty quickly after layer 4. Everything in layers 5-7 is ussally going to be specific to the application and not an additional lay of packet encapsulation like 1-4 are.
>I need to explain OSI model using an example and I am ok with layers 1-4 and 7.
If you understand layers 1-4 and layer 7, you now understand networking as it exists in the modern age. In fact, the CCNA OCG now pushes the "five-layer networking model". (Physical -> Link Layer -> Network -> Transport -> Application)
Although managing the session and presentation of an application is usually important, layers 5 and 6 do not exist in the real world. At least not as a separate layer that exists in all network traffic. Session management and encoding decisions, if required, are handled within Layer 7. The sooner you recognize that, the easier it'll be to fully understand networking.
However, if your question is for a school assignment, then you may need to play the "OSI game" a bit. You're on the right track that selecting ASCII or binary transfer could be considered a layer 6 function. And that managing authentication could be considered a layer 5 function. But just remember in the back of your mind that it's not real.
I never was a big fan of people saying that the OSI model is a "conceptual model". It's not a conceptual model of how networking works. It **was** a model for a real networking stack that competed with, and ultimately lost to, TCP/IP. It's like we're making VHS tapes, but for some reason everyone prefers using Betamax terms, even if it doesn't entirely fit.
Thank you for the explanation. I am a sys admin with limited network knowledge and I have to do this sort of KT session for a group of high school students. So I thought it would be good to explain with a practical example and wanted to check with the networking experts here :)
OSI is now just a concept model since we use Ethernet so you need the Ethernet protocol model which combines 5,6,&7 into Application layer. You can use ftp to conceptualize by saying layer 5 is session and allows the program to differentiate multiple ftp connections, it’s easier to think web browser being able to know which tab in incoming JPEG belongs to. Then layer 6 is the standard, the ftp part of the communication. Finally layer 7 is the application so the cuteftp, or ws_ftp program that is running.
>ASCII / Binary transfer method is an example for layer 6
Given that the entirety of the process is binary, it does you no good to specify that layer 6 is binary. That's just adding words to sound smart without actually describing how the endpoint computer is piping data from the opened socket to the daemon.
IT as a whole is plagued with books and how-to guides and videos that state shit-about-ass regarding what actually happens. Please don't add to the mess if you can.
The initial RFC for FTP is at https://www.ietf.org/rfc/rfc959.txt , though it has been extended with other RFCs multiple times and is a mess to research.
I could be wrong but authentication happens at layer 7 as well, no? It’s either baked into the FTP protocol itself or it leverages another layer 7 protocol like LDAP. IMO layer 5 is strictly about managing the actual TCP AND UDP sessions (assuming TCP/IP of course) on the host. As in closing stale sessions, trying to re open an interrupted session, etc. I don’t see any room in that layer to be fussed with things like user auth. That’s gotta be layer 7. Layer 6 functions might get handled by the application itself in layer 7 too. For example HTTP has aspects of presentation layer functionality built in to it. FTP is likely the same. ASCII encoding happens within the application.
First, one must understand that layers are are a conceptual model, not necessarily something you can touch and feel and point at. In the case of TCP/IP applications, the upper layers are all handled by the same code and as such it becomes difficult to draw fixed lines and say "this function is layer 6 and this function is layer 7". It is a model explaining a concept. It is useful as a tool for explaining a way of thinking. Don't overthink how to apply it to actual applications/code/functions/lines of code. In the case of FTP, the presentation layer is involved in getting credentials from the user. Then said credentials are used at the protocol level. It quickly becomes messy to separate the two. Also, layers 8 to 10 are what most of us are fighting on a daily basis. :-/
I would disagree that the upper layers are all handled by the same code. Layer 5 is OS-layer stuff. Layer 7 is obviously application layer stuff. I also need to disagree that layer 6 is where user creds are gathered. Layer 6 is really focused on data translation, standardization and formatting between layer 5 and 7 and again is largely incorporated into application protocols themselves at layer 7.
Not an expert, so YMMV. I think a better example of Layer 5 would be authentication of hosts via ssh key exchange and cypher agreement. But... I would jump 5 and 6 altogether as long as they get out with a \*VERY\* clear understanding of the rest. :) I can also think about RPC for layer 5. I think Layer 5 spirit is not well presented in FTP, because the session is stablished in the app layer, which is 7.
This is what I also had doubts about. If authentication and encoding of ftp are sort of baked in to ftp then it is hard to say those two function at different layers.
1Layer 1 - Physical Layer: At this layer, the actual physical connection between the devices is established. This could be Ethernet cables, Wi-Fi signals, or any other physical medium. In the case of FTP, this could involve the physical cables connecting the client and server to the network. Layer 2 - Data Link Layer: This layer deals with the addressing of devices on the network and the transmission of data frames. In the case of FTP, this could involve the Ethernet frames used to transmit FTP commands and data between the client and server. Layer 3 - Network Layer: This layer is responsible for routing packets between different networks. In the case of FTP, this could involve the IP packets used to route FTP traffic between the client and server across different networks. Layer 4 - Transport Layer: This layer ensures reliable data transfer between the client and server. In the case of FTP, this could involve the TCP protocol used to establish connections, manage flow control, and ensure data integrity during file transfers. Layer 5 - Session Layer: This layer establishes, manages, and terminates connections between the client and server. In the case of FTP, this could involve the establishment of a session between the client and server, including authentication using a username and password. Layer 6 - Presentation Layer: This layer is responsible for translating, encrypting, or compressing data as needed. In the case of FTP, the choice between ASCII and binary transfer modes could be considered an example of presentation layer functionality. ASCII mode is used for transferring text files, while binary mode is used for transferring non-text files like images or executables. Layer 7 - Application Layer: This layer provides the interface between the user and the network services. In the case of FTP, the user interacts with the FTP client application to initiate file transfers and manage files on the server. And yes, ASCII/Binary transfer method as an example for Layer 6 (Presentation Layer) and using a username and password for authentication as an example for Layer 5 (Session Layer). These practical examples help in understanding how the OSI model applies to real-world network protocols like FTP.
Thank you gpt :p
In the end, “practically” you would need to use ftp over a CLNS connection 🙄. Layers 5-7 really shouldnt be considered to most packet based networks. Understand the OSI model but ultimately little “Practically” uses it.
> I am ok with layers 1-4 Good. Stop there. The osi model doesn't map to reality. We don't design protocols based on osi. Once you realize you're in tcp or udp its usefulness is fully over. --- Still don't believe me? Go read up on how ssh works and then try to map sftp to the osi model. You're going to want to include the ssh channel AND the ftp session negotiation in layer 5 but you're actually in layer 7 of ssh before you can send any ftp commands. The encryption is obvious in ssh but the same problem happens with the data stream in the wrapped ftp data stream. And then you move up to layer 7 and have to decide if "channels" in ssh are actually the session control or if they are wrapped under the larger ssh connection. --- Just learn the three layer model and treat everything about it as "application bs"
Layers 1-3 are useful. Anything after that, just swap to TCP/IP model as that is what's actually used.
Which FTP?
ftp is a service, it uses... wait for it.. all of the layers.
Wait for it, FTP as a service has different modes… oh no! And it has different handling requirements for each, oh bugger! and let’s not cover all the options… holy crap!
this reminds me of jeremy’s tale of 2 packets.
In practice the model breaks down pretty quickly after layer 4. Everything in layers 5-7 is ussally going to be specific to the application and not an additional lay of packet encapsulation like 1-4 are.
>I need to explain OSI model using an example and I am ok with layers 1-4 and 7. If you understand layers 1-4 and layer 7, you now understand networking as it exists in the modern age. In fact, the CCNA OCG now pushes the "five-layer networking model". (Physical -> Link Layer -> Network -> Transport -> Application) Although managing the session and presentation of an application is usually important, layers 5 and 6 do not exist in the real world. At least not as a separate layer that exists in all network traffic. Session management and encoding decisions, if required, are handled within Layer 7. The sooner you recognize that, the easier it'll be to fully understand networking. However, if your question is for a school assignment, then you may need to play the "OSI game" a bit. You're on the right track that selecting ASCII or binary transfer could be considered a layer 6 function. And that managing authentication could be considered a layer 5 function. But just remember in the back of your mind that it's not real. I never was a big fan of people saying that the OSI model is a "conceptual model". It's not a conceptual model of how networking works. It **was** a model for a real networking stack that competed with, and ultimately lost to, TCP/IP. It's like we're making VHS tapes, but for some reason everyone prefers using Betamax terms, even if it doesn't entirely fit.
Thank you for the explanation. I am a sys admin with limited network knowledge and I have to do this sort of KT session for a group of high school students. So I thought it would be good to explain with a practical example and wanted to check with the networking experts here :)
OSI is now just a concept model since we use Ethernet so you need the Ethernet protocol model which combines 5,6,&7 into Application layer. You can use ftp to conceptualize by saying layer 5 is session and allows the program to differentiate multiple ftp connections, it’s easier to think web browser being able to know which tab in incoming JPEG belongs to. Then layer 6 is the standard, the ftp part of the communication. Finally layer 7 is the application so the cuteftp, or ws_ftp program that is running.
>ASCII / Binary transfer method is an example for layer 6 Given that the entirety of the process is binary, it does you no good to specify that layer 6 is binary. That's just adding words to sound smart without actually describing how the endpoint computer is piping data from the opened socket to the daemon. IT as a whole is plagued with books and how-to guides and videos that state shit-about-ass regarding what actually happens. Please don't add to the mess if you can. The initial RFC for FTP is at https://www.ietf.org/rfc/rfc959.txt , though it has been extended with other RFCs multiple times and is a mess to research.