TELNET Reconnection Option NIC 15391 (Aug. 1973) TELNET Reconnection Option 1. Command name and code RCP 2 (prepare to reconnect) 2. Command meanings. IAC DO RCP The sender of this command requests the receiver of the command to be prepared to break the TELNET connection with the sender of the command and to re-establish the TELNET connection with some other party (to be specified later). IAC WILL RCP The receiver of this command agrees to break its TELNET connection to the sender of the DO RCP command and to re-establish the connection with the party to be specified by the sender of the DO RCP command. IAC WON'T RCP The receiver of this command refuses to take part in a reconnection. IAC DON'T RCP The sender of this command demands the cancellation of its previous DO RCP command. IAC SB RCP RCS The sender of this command instructs the receiver of the command to transfer this TELNET connection to the place specified by . The code for RCS is 0. IAC SB RCP RCW The sender of this command instructs the receiver of the command to break the TELNET connection and to await a new TELNET connection from the place specified by . The code for RCW is 1. 1 TELNET Reconnection Option NIC 15391 (Aug. 1973) 3. Default. WON'T RCP i.e., no reconnection is allowed. 4. Motivation for the option. There are situations in which it is desirable to move one or both ends of a communication path from one Host to another. 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 should 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 the executive hand him off to Host2. To do this the executive program would first interact with Host2, telling it to expect a call from the 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 preparatory to doing more elsewhere. The reconnection activity would be invisible to the TIP user. -------- -------- ! EXEC !<--------------------->! USER ! -------- / -------- Host 1 ! / TIP ! / reconnection V / / / -------- ! ! -------- Host 2 FIGURE 1 2 TELNET Reconnection Option NIC 15391 (Aug. 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 undersirable 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 the Host which can then provide him service. 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. The idea is that the shuffling of the user back and forth between Host and Authenticator should be invisible to the user. -------- -------- ! !<--------------------->! USER ! -------- / -------- Host ! / ! / reconnection V / for / authentication / -------- ! ! -------- Authenticator FIGURE 2a 3 TELNET Reconnection Option NIC 15391 (Aug. 1973) -------- -------- ! !<--------------------->! USER ! -------- / -------- Host ^ / ! / ! / authentication / complete / -------- ! ! -------- Authenticator FIGURE 2b C. The McROSS air traffic simulation system (see 1972 SJCC paper by Thomas) already supports reconnection. It permits an on - going simulation to reconfigure itself by allowing parts to move from computer to computer. For example, in a simulation of air traffic in the Northeast, the program fragment simulating the New York Enroute air space could move from Host2 to Host5 (see figure 3). As part of the reconfiguration process the New York Terminal area simulator and Boston Enroute area simulators break their connections with the New York Enroute simulator at Host2 and reconnect to it at Host5. Host 1 Host 2 Host 3 Host 4 -------- ) -------- ( -------- -------- ! NY ! / ! NY ! \ ! BOS ! ! BOS ! ! Term !<--/-->! Enrt !<--\-->! Enrt !<------>! Term ! -------- \ -------- / -------- -------- / \ move / \ / \ ! / \ reconnect \ ! / reconnect \ V / \ / -------- ! NY ! ! Enrt ! -------- Host 5 FIGURE 3 4 TELNET Reconnection Option NIC 15391 (Aug. 1973) 5. An abstract description of a reconnection mechanism. The reconnection mechanism includes four (abstract) commands: Reconnect Request: RRQ Reconnect OK: ROK Reconnect No: RNO Reconnect Do: RDO where is a communication path to be redirected to . Assume that H1 wants to move its end of communication path A-C from itself to port D at H3 (Figure 4). -------- -------- -------- -------- ! C ! ! D ! ! C !<----->! D ! -------- -------- -------- -------- H2 \ H3 H2 H3 \ \ ===> \ -------- -------- ! A ! ! A ! -------- -------- H1 H1 (a) situation (b) desired situation FIGURE 4 The reconnection proceeds by steps: a. H1 arranges for the reconnection by sending RRQ to H2: H1->H2: RRQ (path A-C) b. H2 agrees to reconnect and acknowledges with ROK: H2->H1: ROK (path C-A) c. H1 notes that H2 has agreed to reconnect and instructs H2 to perform the reconnection; H1->H2: RDO (path A-C) (Host H3, PortD) 5 TELNET Reconnection Option NIC 15391 (Aug. 1973) d. H1 breaks paths A-C. H2 breaks path C-A and initiates path C-D. In order for the reconnection to succeed H1 must, of course, have arranged for H3's cooperation. One way H1 could do this would be to establish the path B-D and then proceed through the reconnection protocol exchange with H3 concurrently with its exchange with H2 (See Figure 5): H1->H3: RRQ (path B-D) H3->H1: ROK (path D-B) H1->H3: RDO (path B-D) (Host H2, Port C) -------- -------- ! C ! ^ ^ ! D ! -------- / \ -------- H2 \../.......\../ H3 \/ \/ /\ /\ / \ / \ reconnect -------- reconnect ! A B ! -------- H1 FIGURE 5 Either of the parties may use the RNO command to refuse or abort reconnection. H2 could respond to H1's RRQ with RNO; H1 can abort the reconnection by responding to ROK with RNO rather than RDO. It is easy to insure that messages in transit are not lost during the reconnection. Receipt of the ROK message by H1 is taken to mean that no further messages are coming from H2; similarly receipt of RDO from H1 by H2 is taken to mean that no further messages are coming from H1. To complete the specification of the reconnection mechanism consider the situation in which two "adjacent" entities initiate reconnections: 6 TELNET Reconnection Option NIC 15391 (Aug. 1973) -------- -------- -------- -------- ! C ! ! E ! ! C !-------! E ! -------- -------- -------- -------- H1 H4 H1 H4 ===> -------- -------- -------- -------- ! B !-------! D ! ! B ! ! D ! -------- -------- -------- -------- H2 H3 H2 H3 (a) situation (b) desired situation FIGURE 6 H2 and H3 "simultaneously" try to arrange for reconnection: H2->H3: RRQ (path B-D) H3->H2: RRQ (path D-B) Thus, H2 sees an RRQ from H3 rather than an ROK or RNO in response to its RRQ to H3. This "race" situation can be resolved by having the reconnections proceed in series rather than in parallel: first one entity (say H2) performs its reconnect and then the other (H3) performs its reconnect. There are several means that could be used to decide which gets to go first. Perhaps the simplest is to base the decision on sockets and site addresses: the entity for which the 40 bit number formed by concatenating the 32 bit socket number with the 8 bit site address is largest gets to go first. Using this mechanism the rule is the following: If H2 receives an RRQ from H3 in response to an RRQ of its own: (let NH2, NH3 = the 40 bit numbers corresponding to H2 and H3) a. if NH2>NH3 then both H2 and H3 interpret H3's RRQ as an ROK in response to H2's RRQ. b. if NH2Q !! RRQ ! ---------------- ! --------- ! V ------------------------------ ! Q->P !! ROK ! RNO e! RRQ ! ------------------------------ ! ! ----------- V ! ------------ ! -------yes----! NP > NQ? !----no- ! ! ------------ ! V V V ------------------- ------------------- !P->Q!!RDO e!RNO e! !Q->P!!RDO e!RNO e! ------------------- ------------------- NP and NQ are the 40 bit numbers for P and Q; e indicates end of sequence. 6. A description of the option. The reconnection mechanism described abstractly in the previous section can be effected as a TELNET option by use of the command RCP. Using this command and the TELNET DO, DON'T, WILL, WON'T, and SB prefixes, the four commands used in the previous abstract description become RRQ => DO RCP ROK => WILL RCP RNO => WON'T RCP ;for responses to DO RCP 8 TELNET Reconnection Option NIC 15391 (Aug. 1973) DON'T RCP ;for responses to WILL RCP ;i.e. used to cancel an RCP. RDO => SB RCP RCS A fifth command is also introduced RWT => SB RCP RCW The first three commands require no parameters since they refer to the connections they are received on. For RDO and RWT, is an 8 bit (= 1 TELNET character) Host address and is a 32 bit (= 4 TELNET characters) number that specifies a TELNET receive socket at the specified Host (the associated transmit socket is always one higher than the receive socket. A pending reconnection can be activiated with either RDO or RWT. The response to either is to first break the TELNET connection with the sender and then reopen the TELNET connection to the Host and sockets specified. For RDO, the connection is to be reopened by sending two RFC'c; for RWT, by waiting for two RFC's. The RWT command is introduced to avoid requiring Hosts to queue RFC's. As an example, the reconnnection H2 H3 H2 H3 -------- -------- -------- m -------- ! Y ! ! Z ! ! Y !------>! Z ! ! ! ! ! ! !<------! ! -------- -------- -------- n -------- n\ \ p/ / \ \ / / \ \m / / \ -------- /q ===> -------- ! X ! ! X ! ! ! ! ! -------- -------- H1 H1 could be accomplished as follows: X->Y: RRQ (=IAC DO RCP) X->Z: RRQ (=IAC DO RCP) 9 TELNET Reconnection Option NIC 15391 (Aug. 1973) Y->X: ROK (=IAC WILL RCP) Z->X: ROK (=IAC WILL RCP) X->Y: RWT H3 P (=IAC SB RCP RCW H3 P) X closes connections to Y Y closes connections to X Y waits for STR and RTS from H3 X->Z: RDO H2 N (=IAC SB RCP RCS H2 N) X closes connections to Z Z closes connections to X Z sends STR and RTS to H2 which Y answers with matching RTS and STR to compete reconnection The RCS and RCW sub-commands should never be sent until a DO RCP has been acknowledged by a WILL RCP. Thus a Host not choosing to implement the reconnection option does not have to know what RCP means--all the Host need do in response to DO RCP is to transmit WON'T RCP. The WILL RCP and WON'T RCP commands should never be volunteered. If an unsolicited WILL RCP is ever received, a DON'T RCP should be fired back, which should be answered by a WON'T RCP command. If an unsolicited WON'T RCP command is received, it should be treated as a No-operation. 7. A word about security. It should be clear that the decision to accept or reject a particular reconnection request is the responsibility of the entity (person at the terminal or process) using the connection. In many cases the entity may chose to delegate that responsibility to its TELNET (e.g., Example A, Section 4). However, the interface a Host provides to the reconnection mechanism would best include means for local entities to exercise control over response to remotely intitiated reconnection requests. For example, a user-TELNET might support several modes of operation with respect to remotely initiated reconnections: 1. transparent: all requested reconnections are to be performed in a way that is invisible to the user; 2. visible: all requested reconnections are to be performed and the user is to be informed whenever a reconnection occurs; 3. confirmation: the user is to be informed of each reconnection request which he may accept or reject; 4. rejection: all requested reconnects are to be rejected. 10