Telnet applies to any host or terminal. The client's operating system maps a terminal to a network virtual terminal (NVT) regardless of the terminal's type. Then, the server maps the NVT into a supported terminal type. This mapping masks client and terminal types. Communicating ends are assumed to be connected to the NVTs.
Telnet uses the symmetric client/server mode. Therefore, each end of a Telnet connection must have an NVT.
Two communicating ends negotiate options by sending WILL, WONT, DO, and DONT requests. The options are used to determine the content of the Telnet service and include the echo information, command change character set, and line mode.
Either communicating end can initiate a request. Table 1 describes requests in Telnet.
Request From the Sender |
Description |
Response From the Receiver |
|||
---|---|---|---|---|---|
- |
- |
WILL |
WONT |
DO |
DONT |
WILL |
The sender wants to enable an option. |
- |
- |
The receiver grants the request. |
The receiver rejects the request. |
WONT |
The sender wants to disable an option. |
- |
- |
- |
The receiver must grant the request. |
DO |
The sender wants the receiver to enable an option. |
The receiver grants the request. |
The receiver rejects the request. |
- |
- |
DONT |
The sender wants the receiver to disable an option. |
- |
The receiver must grant the request. |
- |
- |
When the sender sends a WONT or DONT request, the receiver must grant the request.
If the receiver grants the request, the option immediately takes effect.
If the receiver rejects the request, the option does not take effect. The sender can still retain the NVT function.
Option negotiation requires the following three items:
< IAC, WILL/DO/WONT/DONT, option >
The following is an example of option negotiation.
The server wants to enable option 33 "remote traffic control" and the client grants the request. The exchanged commands are as follows:
On the server: <IAC, WILL, 33>
On the client: <IAC, DO, 33>
In addition to an option ID, other information may be required. For example, if the receiver is required to specify a terminal type, the receiver must respond with an American Standard Code for Information Interchange (ASCII) string to identify the terminal type.
The format of suboption negotiation is as follows:
<IAC, SB, option ID, suboption content, IAC, SE>
A complete suboption negotiation process is as follows:
The sender asks to enable the option by sending a DO/WILL request carrying the option ID.
The receiver grants the request by sending a WILL/DO request carrying the option ID.
Through the preceding steps, both communicating ends agree to enable the option.
Either communicating end sends the request carrying the suboption ID through the suboption-begin (SB) command and ends the suboption negotiation through the suboption-end (SE) command.
The other end responds to the suboption negotiation through the SB command, suboption codes, and related negotiation information, and then ends the suboption.
The receiver responds with a DO/WILL message to grant the request.
If there is no other suboption to be negotiated, the current negotiation is complete.
Assume, for demonstration purposes, that the receiver grants the request from the sender.
In practice, the receiver can reject the request from the server at any time.
The following is an example of terminal type negotiation.
The client wants to enable the "terminal type" option (option ID is 24). The server grants the request and asks the client what its terminal type is. The client responds to the server with its terminal type "DELL PC". The exchanged commands are as follows:
From the client: <IAC, WILL, 24>
From the server: <IAC, DO, 24>
From the server: <IAC, SB, 24, 1, IAC, SE>
From the client: <IAC, SB, 24, 0, 'D', 'E', 'L', 'L', 'P', 'C', IAC, SE>
The sender can request the terminal type only when the option negotiation type is DO.
The sender can relay the actual terminal type only when the option negotiation type is WILL.
The terminal type cannot be sent automatically. It is sent only for responding to the request, that is, it is sent in request-response mode.
The terminal type information is a case-insensitive NVT ASCII string.
Telnet supports the following operating modes:
Half-duplex
One character at a time
One line at a time
Line mode
Symmetry in the negotiation syntax allows either the client or server to request a particular option as required, which optimizes the services provided by the other party. A terminal protocol allows a terminal to interact with an application process on a host. It also allows process-process and terminal-terminal interactions.
Telnet clients allow access to IPv6 host addresses, and Telnet servers can receive IPv6 connection requests.