Yesterday’s Technology – Telnet Protocol

There was a single driver behind the development of the Telnet protocol – compatibility. The idea was that telnet could work with any host or operating system without difficulty. It was also important that the protocol could work using any sort of terminal (or keyboard).

The protocol was initially specified in RFC 854 where it defined a lowest common denominator terminal called a NVT (network virtual terminal). This is actually an imaginary or virtual device which exists at both ends of the connection i.e. client and server. Both devices should map onto this NVT, so the client would map while specifying OS and terminal type whilst the server must do the same thing. Effectively both are mapping onto the NVT which creates a bridge across the two different systems to enable the connection rather line this VPN technology here.

An important specification to remember is NVT ASCII which refers to the 7 bit variant of the famous character set used by the internet protocol suite. Each character (7 bit) is sent as an 8 bit byte with the high order bit set to 0. It’s important to remember this definition as it supports many of the commands and functionality contained in Telnet.

The telnet operation actually uses in-band signalling in both directions. The byte 255 decimal is sent which states interpret as command (IAC). The following byte is the actual command byte in all circumstances. In order to specify the data byte, two consecutive 255 bytes are sent. Telnet has a surprising number of commands but as it’s rarely used in modern times, then the majority of them are rarely used.

Although Telnet by default assumes the existence of an NVT – the initial exchange is one of option negotiation. This exchange is symmetric (requests can be sent from each side) and the requests can be one of four main options. These are WILL, DO, WONT or DONT and refer to following settings –

  • WILL – Sender Enables Options
  • DO – Sender wants receiver to enable option
  • WONT – Sender wants to disable option
  • DONT – Sender wants receiver to disable option

The Telnet protocol requires that either side can reject or accept any request to enable an option but must honor a request to disable. This allows the telnet protocol to ensure that specific requirements to disable options are always honoured. These are important because they usually are required to support the various terminals used.

Remember Telnet option negotiation like the rest of the protocol is designed to be symmetrical. This means that either end of the connection can initiate negotiation of any option supported by the protocol.

Further Readings:

Leave a Reply

Your email address will not be published. Required fields are marked *