Reconnection Protocol
RFC 426

Document Type RFC - Unknown (January 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 426 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         Bob Thomas
Request for Comments: 426                                      BBN-TENEX
NIC: 13011                                               23 January 1973
Categories: Protocols, TELNET
References: 36,318,333,435

                         Reconnection Protocol

   There are situations in which it is desirable to move one or both
   ends of a communication path from one host to another.  This note
   describes several situations in which the ability to reconnect is
   useful, presents a mechanism to achieve reconnection, sketches how
   the mechanism could be added to Host-Host or TELNET protocol, and
   recommends a place for the mechanism in the protocol hierarchy.

1. Some Examples:

A. Consider the case of an executive program which TIP users could use
   to get network status information, send messages, link to other
   users, etc.  Due to the TIP's limited resources the executive program
   would probably not run on the TIP itself but rather would run on one
   or more larger hosts who would be willing to share some of their
   resources with the TIP (see Figure 1).

   The TIP user could access the executive by typing a command such as
   "@ EXEC"; the TIP would then ICP to Host1's executive port.  After
   obtaining the latest network news and perhaps sending a few messages,
   the user would be ready to log into Host2 (in general not the same as
   Host1) and do some work.  At that point he would like to tell the
   executive program that he is ready to use Host2 and have executive
   hand him off to Host2.  To do this the executive program would first
   interact with Host2, telling it to expect a call from TIP, and then
   would instruct the TIP to reconnect to Host2.  When the user logs off
   Host2 he could be passed back to the executive at Host1 prepatory to
   doing more work elsewhere. The reconnection activity would be
   invisible to the TIP user.
          ______               |              ______
         |      |              |             |      |
         | EXEC |<-------------+------------>| USER |
         |______|              |  /          |______|
           Host1               V /              TIP
                 ______         /
                |      |<------/
                               Figure 1

Thomas                                                          [Page 1]
RFC 426                  Reconnection Protocol              January 1973

B. Imagine a scenario in which a user could use the same name and
   password (and perhaps account) to log into any server on the network.
   For reasons of security and economy it would be undesirable to have
   every name and password stored at every site.  A user wanting to use
   a Host that doesn't have his name or password locally would connect
   to it and attempt to log in as usual (See Figure 2).  The Host,
   discovering that it doesn't know the user, would hand him off to a
   network authentication service which can determine whether the user
   is who he claims to be. If the user passes the authentication test he
   can be handed back to Host which can then provide him service.  The
   idea is that the shuffling of the user back and forth between Host
   and Authenticator should invisible to the user.

   (a)   ______      for authentication     ______
        |      |            |              |      |
        |      |<-----------+------------->| User |
        |______|            | /            |______|
          Host              |/
             _______      / |
            |       |    /  v
            |       |<---

         ______                             ______
        |      |                           |      |
        |      |<--\             ^     /-->| User |
        |______|    \            |    /    |______|
          Host       \           |   /
                                 | /
                               / |
                              /  | authentication
             _______         /   | complete
            |       |       /
            |       |<------

                           Figure 2

Thomas                                                          [Page 2]
RFC 426                  Reconnection Protocol              January 1973

   If the user doesn't trust the Host and is afraid that it might read
   his password rather than pass him off to the authenticator he could
   connect directly to the authentication service.  After
   authentication, the Authenticator can pass him off to the Host.

C. The McROSS air traffic simulation system (see 1972 SJCC paper)
Show full document text