[Docs] [txt|pdf] [Errata]
Updated by: 5198 INTERNET STANDARD
Errata Exist
Network Working Group J. Postel
Request for Comments: 854 J. Reynolds
ISI
Obsoletes: NIC 18639 May 1983
TELNET PROTOCOL SPECIFICATION
This RFC specifies a standard for the ARPA Internet community. Hosts on
the ARPA Internet are expected to adopt and implement this standard.
INTRODUCTION
The purpose of the TELNET Protocol is to provide a fairly general,
bi-directional, eight-bit byte oriented communications facility. Its
primary goal is to allow a standard method of interfacing terminal
devices and terminal-oriented processes to each other. It is
envisioned that the protocol may also be used for terminal-terminal
communication ("linking") and process-process communication
(distributed computation).
GENERAL CONSIDERATIONS
A TELNET connection is a Transmission Control Protocol (TCP)
connection used to transmit data with interspersed TELNET control
information.
The TELNET Protocol is built upon three main ideas: first, the
concept of a "Network Virtual Terminal"; second, the principle of
negotiated options; and third, a symmetric view of terminals and
processes.
1. When a TELNET connection is first established, each end is
assumed to originate and terminate at a "Network Virtual Terminal",
or NVT. An NVT is an imaginary device which provides a standard,
network-wide, intermediate representation of a canonical terminal.
This eliminates the need for "server" and "user" hosts to keep
information about the characteristics of each other's terminals and
terminal handling conventions. All hosts, both user and server, map
their local device characteristics and conventions so as to appear to
be dealing with an NVT over the network, and each can assume a
similar mapping by the other party. The NVT is intended to strike a
balance between being overly restricted (not providing hosts a rich
enough vocabulary for mapping into their local character sets), and
being overly inclusive (penalizing users with modest terminals).
NOTE: The "user" host is the host to which the physical terminal
is normally attached, and the "server" host is the host which is
normally providing some service. As an alternate point of view,
Postel & Reynolds [Page 1]
RFC 854 May 1983
applicable even in terminal-to-terminal or process-to-process
communications, the "user" host is the host which initiated the
communication.
2. The principle of negotiated options takes cognizance of the fact
that many hosts will wish to provide additional services over and
above those available within an NVT, and many users will have
sophisticated terminals and would like to have elegant, rather than
minimal, services. Independent of, but structured within the TELNET
Protocol are various "options" that will be sanctioned and may be
used with the "DO, DON'T, WILL, WON'T" structure (discussed below) to
allow a user and server to agree to use a more elaborate (or perhaps
just different) set of conventions for their TELNET connection. Such
options could include changing the character set, the echo mode, etc.
The basic strategy for setting up the use of options is to have
either party (or both) initiate a request that some option take
effect. The other party may then either accept or reject the
request. If the request is accepted the option immediately takes
effect; if it is rejected the associated aspect of the connection
remains as specified for an NVT. Clearly, a party may always refuse
a request to enable, and must never refuse a request to disable some
option since all parties must be prepared to support the NVT.
The syntax of option negotiation has been set up so that if both
parties request an option simultaneously, each will see the other's
request as the positive acknowledgment of its own.
3. The symmetry of the negotiation syntax can potentially lead to
nonterminating acknowledgment loops -- each party seeing the incoming
commands not as acknowledgments but as new requests which must be
acknowledged. To prevent such loops, the following rules prevail:
a. Parties may only request a change in option status; i.e., a
party may not send out a "request" merely to announce what mode it
is in.
b. If a party receives what appears to be a request to enter some
mode it is already in, the request should not be acknowledged.
This non-response is essential to prevent endless loops in the
negotiation. It is required that a response be sent to requests
for a change of mode -- even if the mode is not changed.
c. Whenever one party sends an option command to a second party,
whether as a request or an acknowledgment, and use of the option
will have any effect on the processing of the data being sent from
the first party to the second, then the command must be inserted
in the data stream at the point where it is desired that it take
Postel & Reynolds [Page 2]
RFC 854 May 1983
effect. (It should be noted that some time will elapse between
the transmission of a request and the receipt of an
acknowledgment, which may be negative. Thus, a host may wish to
buffer data, after requesting an option, until it learns whether
the request is accepted or rejected, in order to hide the
"uncertainty period" from the user.)
Option requests are likely to flurry back and forth when a TELNET
connection is first established, as each party attempts to get the
best possible service from the other party. Beyond that, however,
options can be used to dynamically modify the characteristics of the
connection to suit changing local conditions. For example, the NVT,
as will be explained later, uses a transmission discipline well
suited to the many "line at a time" applications such as BASIC, but
poorly suited to the many "character at a time" applications such as
NLS. A server might elect to devote the extra processor overhead
required for a "character at a time" discipline when it was suitable
for the local process and would negotiate an appropriate option.
However, rather than then being permanently burdened with the extra
processing overhead, it could switch (i.e., negotiate) back to NVT
when the detailed control was no longer necessary.
It is possible for requests initiated by processes to stimulate a
nonterminating request loop if the process responds to a rejection by
merely re-requesting the option. To prevent such loops from
occurring, rejected requests should not be repeated until something
changes. Operationally, this can mean the process is running a
different program, or the user has given another command, or whatever
makes sense in the context of the given process and the given option.
A good rule of thumb is that a re-request should only occur as a
result of subsequent information from the other end of the connection
or when demanded by local human intervention.
Option designers should not feel constrained by the somewhat limited
syntax available for option negotiation. The intent of the simple
syntax is to make it easy to have options -- since it is
correspondingly easy to profess ignorance about them. If some
particular option requires a richer negotiation structure than
possible within "DO, DON'T, WILL, WON'T", the proper tack is to use
"DO, DON'T, WILL, WON'T" to establish that both parties understand
the option, and once this is accomplished a more exotic syntax can be
used freely. For example, a party might send a request to alter
(establish) line length. If it is accepted, then a different syntax
can be used for actually negotiating the line length -- such a
"sub-negotiation" might include fields for minimum allowable, maximum
allowable and desired line lengths. The important concept is that
Postel & Reynolds [Page 3]
RFC 854 May 1983
such expanded negotiations should never begin until some prior
(standard) negotiation has established that both parties are capable
of parsing the expanded syntax.
In summary, WILL XXX is sent, by either party, to indicate that
party's desire (offer) to begin performing option XXX, DO XXX and
DON'T XXX being its positive and negative acknowledgments; similarly,
DO XXX is sent to indicate a desire (request) that the other party
(i.e., the recipient of the DO) begin performing option XXX, WILL XXX
and WON'T XXX being the positive and negative acknowledgments. Since
the NVT is what is left when no options are enabled, the DON'T and
WON'T responses are guaranteed to leave the connection in a state
which both ends can handle. Thus, all hosts may implement their
TELNET processes to be totally unaware of options that are not
supported, simply returning a rejection to (i.e., refusing) any
option request that cannot be understood.
As much as possible, the TELNET protocol has been made server-user
symmetrical so that it easily and naturally covers the user-user
(linking) and server-server (cooperating processes) cases. It is
hoped, but not absolutely required, that options will further this
intent. In any case, it is explicitly acknowledged that symmetry is
an operating principle rather than an ironclad rule.
A companion document, "TELNET Option Specifications," should be
consulted for information about the procedure for establishing new
options.
STANDARD REPRESENTATION OF CONTROL FUNCTIONS
As stated in the Introduction to this document, the primary goal
of the TELNET protocol is the provision of a standard interfacing
of terminal devices and terminal-oriented processes through the
network. Early experiences with this type of interconnection have
shown that certain functions are implemented by most servers, but
that the methods of invoking these functions differ widely. For a
human user who interacts with several server systems, these
differences are highly frustrating. TELNET, therefore, defines a
standard representation for five of these functions, as described
Postel & Reynolds [Page 6]
RFC 854 May 1983
below. These standard representations have standard, but not
required, meanings (with the exception that the Interrupt Process
(IP) function may be required by other protocols which use
TELNET); that is, a system which does not provide the function to
local users need not provide it to network users and may treat the
standard representation for the function as a No-operation. On
the other hand, a system which does provide the function to a
local user is obliged to provide the same function to a network
user who transmits the standard representation for the function.
Interrupt Process (IP)
CTRL-C
Abort Output (AO)
TELL THE OTHER END TO STOP SENDING THE OUTPUT OF THE CURRENTLY
EXECUTING PROCESS. (CTRL-O)
Postel & Reynolds [Page 7]
RFC 854 May 1983
Are You There (AYT)
MORE COMMONLY REFERRED TO THESE DAYS AS PING OR PROBE
(AND RELATED TO KEEPALIVE).
Erase Character (EC)
BACKSPACE
Erase Line (EL)
CTRL-U
THE TELNET "SYNCH" SIGNAL
Most time-sharing systems provide mechanisms which allow a
terminal user to regain control of a "runaway" process; the IP and
AO functions described above are examples of these mechanisms.
Such systems, when used locally, have access to all of the signals
supplied by the user, whether these are normal characters or
special "out of band" signals such as those supplied by the
teletype "BREAK" key or the IBM 2741 "ATTN" key. This is not
necessarily true when terminals are connected to the system
through the network; the network's flow control mechanisms may
cause such a signal to be buffered elsewhere, for example in the
user's host.
Postel & Reynolds [Page 8]
RFC 854 May 1983
To counter this problem, the TELNET "Synch" mechanism is
introduced. A Synch signal consists of a TCP Urgent notification,
coupled with the TELNET command DATA MARK. The Urgent
notification, which is not subject to the flow control pertaining
to the TELNET connection, is used to invoke special handling of
the data stream by the process which receives it. In this mode,
the data stream is immediately scanned for "interesting" signals
as defined below, discarding intervening data. The TELNET command
DATA MARK (DM) is the synchronizing mark in the data stream which
indicates that any special signal has already occurred and the
recipient can return to normal processing of the data stream.
The Synch is sent via the TCP send operation with the Urgent
flag set and the DM as the last (or only) data octet.
When several Synchs are sent in rapid succession, the Urgent
notifications may be merged. It is not possible to count Urgents
since the number received will be less than or equal the number
sent. When in normal mode, a DM is a no operation; when in urgent
mode, it signals the end of the urgent processing.
If TCP indicates the end of Urgent data before the DM is found,
TELNET should continue the special handling of the data stream
until the DM is found.
If TCP indicates more Urgent data after the DM is found, it can
only be because of a subsequent Synch. TELNET should continue
the special handling of the data stream until another DM is
found.
"Interesting" signals are defined to be: the TELNET standard
representations of IP, AO, and AYT (but not EC or EL); the local
analogs of these standard representations (if any); all other
TELNET commands; other site-defined signals which can be acted on
without delaying the scan of the data stream.
Since one effect of the SYNCH mechanism is the discarding of
essentially all characters (except TELNET commands) between the
sender of the Synch and its recipient, this mechanism is specified
as the standard way to clear the data path when that is desired.
For example, if a user at a terminal causes an AO to be
transmitted, the server which receives the AO (if it provides that
function at all) should return a Synch to the user.
Finally, just as the TCP Urgent notification is needed at the
TELNET level as an out-of-band signal, so other protocols which
make use of TELNET may require a TELNET command which can be
viewed as an out-of-band signal at a different level.
Postel & Reynolds [Page 9]
RFC 854 May 1983
By convention the sequence [IP, Synch] is to be used as such a
signal. For example, suppose that some other protocol, which uses
TELNET, defines the character string STOP analogously to the
TELNET command AO. Imagine that a user of this protocol wishes a
server to process the STOP string, but the connection is blocked
because the server is processing other commands. The user should
instruct his system to:
1. Send the TELNET IP character;
2. Send the TELNET SYNC sequence, that is:
Send the Data Mark (DM) as the only character
in a TCP urgent mode send operation.
3. Send the character string STOP; and
4. Send the other protocol's analog of the TELNET DM, if any.
The user (or process acting on his behalf) must transmit the
TELNET SYNCH sequence of step 2 above to ensure that the TELNET IP
gets through to the server's TELNET interpreter.
The Urgent should wake up the TELNET process; the IP should
wake up the next higher level process.
TELNET COMMAND STRUCTURE
All TELNET commands consist of at least a two byte sequence: the
"Interpret as Command" (IAC) escape character followed by the code
for the command. The commands dealing with option negotiation are
three byte sequences, the third byte being the code for the option
referenced. This format was chosen so that as more comprehensive use
of the "data space" is made -- by negotiations from the basic NVT, of
course -- collisions of data bytes with reserved command values will
be minimized, all such collisions requiring the inconvenience, and
Postel & Reynolds [Page 13]
RFC 854 May 1983
inefficiency, of "escaping" the data bytes into the stream. With the
current set-up, only the IAC need be doubled to be sent as data, and
the other 255 codes may be passed transparently.
The following are the defined TELNET commands. Note that these codes
and code sequences have the indicated meaning only when immediately
preceded by an IAC.
NAME CODE MEANING
SE 240 End of subnegotiation parameters.
NOP 241 No operation.
Data Mark 242 The data stream portion of a Synch.
This should always be accompanied
by a TCP Urgent notification.
Break 243 NVT character BRK.
Interrupt Process 244 The function IP.
Abort output 245 The function AO.
Are You There 246 The function AYT.
Erase character 247 The function EC.
Erase Line 248 The function EL.
Go ahead 249 The GA signal.
SB 250 Indicates that what follows is
subnegotiation of the indicated
option.
WILL (option code) 251 Indicates the desire to begin
performing, or confirmation that
you are now performing, the
indicated option.
WON'T (option code) 252 Indicates the refusal to perform,
or continue performing, the
indicated option.
DO (option code) 253 Indicates the request that the
other party perform, or
confirmation that you are expecting
the other party to perform, the
indicated option.
DON'T (option code) 254 Indicates the demand that the
other party stop performing,
or confirmation that you are no
longer expecting the other party
to perform, the indicated option.
IAC 255 Data Byte 255.
Postel & Reynolds [Page 14]
RFC 854 May 1983
CONNECTION ESTABLISHMENT
The TELNET TCP connection is established between the user's port U
and the server's port L. The server listens on its well known port L
for such connections. Since a TCP connection is full duplex and
identified by the pair of ports, the server can engage in many
simultaneous connections involving its port L and different user
ports U.
Port Assignment
When used for remote user access to service hosts (i.e., remote
terminal access) this protocol is assigned server port 23
(27 octal). That is L=23.
Postel & Reynolds [Page 15]
Html markup produced by rfcmarkup 1.107, available from
http://tools.ietf.org/tools/rfcmarkup/