BSD Rlogin
RFC 1282

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• rfc1282

Network Working Group                                          B. Kantor
Request for Comments: 1282                      Univ. of Calif San Diego
Obsoletes: RFC 1258                                        December 1991

                               BSD Rlogin

Status of this Memo

   This memo documents an existing protocol and common implementation
   that is extensively used on the Internet.  This memo provides
   information for the Internet community.  It does not specify an
   Internet standard.  Distribution of this memo is unlimited.

Protocol Description

   The rlogin facility provides a remote-echoed, locally flow-controlled
   virtual terminal with proper flushing of output [1].  It is widely
   used between Unix hosts because it provides transport of more of the
   Unix terminal environment semantics than does the Telnet protocol,
   and because on many Unix hosts it can be configured not to require
   user entry of passwords when connections originate from trusted
   hosts.

   The rlogin protocol requires the use of the TCP.  The contact port is
   513.  An eight-bit transparent stream is assumed.

Connection Establishment

   Upon connection establishment, the client sends four null-terminated
   strings to the server.  The first is an empty string (i.e., it
   consists solely of a single zero byte), followed by three non-null
   strings: the client username, the server username, and the terminal
   type and speed.  More explicitly:

        <null>
        client-user-name<null>
        server-user-name<null>
        terminal-type/speed<null>

        For example:

        <null>
        bostic<null>
        kbostic<null>
        vt100/9600<null>

   The server returns a zero byte to indicate that it has received these

Kantor                                                          [Page 1]
RFC 1282                       BSD Rlogin                  December 1991

   strings and is now in data transfer mode.  Window size negotiation
   may follow this initial exchange (see below).

From Client to Server (and Flow Control)

   Initially, the client begins operation in "cooked" (as opposed to
   to "raw") mode.  In this mode, the START and STOP (usually ASCII
   DC1,DC3) characters are intercepted and interpreted by the client to
   start and stop output from the remote server to the local terminal,
   whereas all other characters are transmitted to the remote host as
   they are received.  (But see below for the handling of the
   local-escape character.)

   In "raw" mode, the START and STOP characters are not processed
   locally, but are sent as any other character to the remote server.
   The server thus determines the semantics of the START and STOP
   characters when in "raw" mode; they may be used for flow control or
   have quite different meanings independent of their ordinary usage on
   the client.

Screen/Window Size

   The remote server indicates to the client that it can accept window
   size change information by requesting a window size message (as out
   of band data) just after connection establishment and user
   identification exchange.  The client should reply to this request
   with the current window size.

   If the remote server has indicated that it can accept client window
   size changes and the size of the client's window or screen dimensions
   changes, a 12-byte special sequence is sent to the remote server to
   indicate the current dimensions of the client's window, should the
   user process running on the server care to make use of that
   information.

   The window change control sequence is 12 bytes in length, consisting
   of a magic cookie (two consecutive bytes of hex FF), followed by two
   bytes containing lower-case ASCII "s", then 8 bytes containing the
   16-bit values for the number of character rows, the number of
   characters per row, the number of pixels in the X direction, and the
   number of pixels in the Y direction, in network byte order.  Thus:

        FF FF s s rr cc xp yp

   Other flags than "ss" may be used in future for other in-band control
   messages.  None are currently defined.

Kantor                                                          [Page 2]
RFC 1282                       BSD Rlogin                  December 1991

From Server to Client

   Data from the remote server is sent to the client as a stream of
   characters.  Normal data is simply sent to the client's display, but
   may be processed before actual display (tabs expanded, etc.).

   The server can imbed single-byte control messages in the data stream
   by inserting the control byte in the stream of data and pointing the
   TCP "urgent-data" pointer at the control byte.  When a TCP urgent-
   data pointer is received by the client, data in the TCP stream up to
   the urgent byte is buffered for possible display after the control
   byte is handled, and the control byte pointed to is received and
   interpreted as follows:

02   A control byte of hex 02 causes the client to discard all buffered