Browse Prior Art Database

Reconnection Protocol (RFC0426) Disclosure Number: IPCOM000004919D
Original Publication Date: 1973-Jan-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 12 page(s) / 15K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Thomas: AUTHOR

Related Documents

10.17487/RFC0426: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 15% of the total text.

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. Reconnection ______ | ______ | | | | | | EXEC |<-------------+------------>| USER | |______| | / |______| Host1 V / TIP ______ / | |<------/ |______| Host2 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 |/ X /| _______ / | | | / v | |<--- |_______| Authenticator

(b) ______ ______ | | | | | |<--\ ^ /-->| User | |______| \ | / |______| Hos...