3. Remote Login - Protocollo TELNET
3.1 INTRODUZIONE
Telnet è il protocollo applicativo Internet standard per il login remoto. Fornisce le regole di codifica per collegare la tastiera/display di un utente su un sistema client (「utente」) con un interprete di comandi su un sistema server remoto. Un sottoinsieme del protocollo Telnet è incorporato anche in altri protocolli applicativi, ad esempio FTP e SMTP.
Telnet utilizza una singola connessione TCP e il suo flusso dati normale (modalità «Terminale Virtuale di Rete» o «NVT») è ASCII a 7 bit con sequenze di escape per incorporare funzioni di controllo. Telnet consente anche la negoziazione di molti modi e funzioni opzionali.
La specifica Telnet primaria si trova in RFC-854 [TELNET:1], mentre le opzioni sono definite in molti altri RFC; vedere Sezione 7 per i riferimenti.
3.2 PROCEDURA DEL PROTOCOLLO
3.2.1 Negoziazione delle opzioni: RFC-854, pp. 2-3
Ogni implementazione Telnet deve (MUST) includere il meccanismo di negoziazione e sotto-negoziazione delle opzioni [TELNET:2].
Un host deve (MUST) seguire attentamente le regole di RFC-854 per evitare loop di negoziazione delle opzioni. Un host deve (MUST) rifiutare (cioè rispondere WONT/DONT a un DO/WILL) un'opzione non supportata. La negoziazione delle opzioni dovrebbe (SHOULD) continuare a funzionare (anche se tutte le richieste vengono rifiutate) per tutta la durata di una connessione Telnet.
Se tutte le negoziazioni delle opzioni falliscono, un'implementazione Telnet deve (MUST) impostare per default e supportare un NVT.
DISCUSSIONE:
Anche se «terminali» più sofisticati e negoziazioni di opzioni di supporto stanno diventando la norma, tutte le implementazioni devono essere preparate a supportare un NVT per qualsiasi comunicazione utente-server.
3.2.2 Funzione Go-Ahead di Telnet: RFC-854, p. 5, e RFC-858
Su un host che non invia mai il comando Telnet Go Ahead (GA), il server Telnet deve (MUST) tentare di negoziare l'opzione Suppress Go Ahead (cioè inviare «WILL Suppress Go Ahead»). Un Telnet utente o server deve (MUST) sempre accettare la negoziazione dell'opzione Suppress Go Ahead.
Quando sta guidando un terminale full-duplex per il quale GA non ha significato, un'implementazione Telnet utente può (MAY) ignorare i comandi GA.
DISCUSSIONE:
I terminali half-duplex («tastiera bloccata») linea per linea per i quali è stato progettato il meccanismo Go-Ahead sono largamente scomparsi dalla scena. Si è rivelato difficile implementare l'invio del segnale Go-Ahead in molti sistemi operativi, anche alcuni sistemi che supportano terminali half-duplex nativi. La difficoltà è tipicamente che il codice del server Telnet non ha accesso alle informazioni su se il processo utente è bloccato in attesa di input dalla connessione Telnet, cioè non può determinare in modo affidabile quando inviare un comando GA. Pertanto, la maggior parte degli host server Telnet non invia comandi GA.
L'effetto delle regole in questa sezione è di permettere a una delle due estremità di una connessione Telnet di porre il veto all'uso dei comandi GA.
C'è una classe di terminali half-duplex che è ancora commercialmente importante: i «terminali di immissione dati», che interagiscono in modo a schermo intero. Tuttavia, supportare i terminali di immissione dati utilizzando il protocollo Telnet non richiede il segnale Go Ahead; vedere Sezione 3.3.2.
3.2.3 Funzioni di controllo: RFC-854, pp. 7-8
L'elenco dei comandi Telnet è stato esteso per includere EOR (End-of-Record), con codice 239 [TELNET:9].
Sia i Telnet utente che server possono (MAY) supportare le funzioni di controllo EOR, EC, EL e Break, e devono (MUST) supportare AO, AYT, DM, IP, NOP, SB e SE.
Un host deve (MUST) essere in grado di ricevere e ignorare qualsiasi funzione di controllo Telnet che non supporta.
DISCUSSIONE:
Si noti che un server Telnet è richiesto di supportare la funzione Telnet IP (Interrupt Process), anche se l'host server ha un equivalente funzione in-stream (ad esempio Control-C in molti sistemi). La funzione Telnet IP può essere più forte di un comando di interruzione in-stream, a causa dell'effetto fuori banda dei dati urgenti TCP.
La funzione di controllo EOR può essere utilizzata per delimitare il flusso. Un'applicazione importante è il supporto dei terminali di immissione dati (vedere Sezione 3.3.2). C'era preoccupazione che poiché EOR non era stato definito in RFC-854, un host che non era preparato a ignorare correttamente comandi Telnet sconosciuti potrebbe bloccarsi se riceveva un EOR. Per proteggere tali host, l'opzione End-of-Record [TELNET:9] è stata introdotta; tuttavia, un programma Telnet implementato correttamente non richiederà questa protezione.
3.2.4 Segnale "Synch" di Telnet: RFC-854, pp. 8-10
Quando riceve dati TCP «urgenti», un Telnet utente o server deve (MUST) scartare tutti i dati eccetto i comandi Telnet fino a quando non viene raggiunto il DM (e la fine dell'urgente).
Quando invia Telnet IP (Interrupt Process), un Telnet utente dovrebbe (SHOULD) farlo seguire dalla sequenza «Synch» di Telnet, cioè inviare come dati TCP urgenti la sequenza «IAC IP IAC DM». Il puntatore urgente TCP punta all'ottetto DM.
Quando riceve un comando Telnet IP, un server Telnet può (MAY) inviare una sequenza «Synch» di Telnet all'utente, per svuotare il flusso di output. La scelta dovrebbe essere coerente con il modo in cui il sistema operativo server si comporta quando un utente locale interrompe un processo.
Quando riceve un comando Telnet AO, un server Telnet deve (MUST) inviare una sequenza «Synch» di Telnet all'utente, per svuotare il flusso di output.
Un Telnet utente dovrebbe (SHOULD) avere la capacità di svuotare l'output quando invia un Telnet IP; vedere anche Sezione 3.4.5.
DISCUSSIONE:
Ci sono tre modi possibili per un Telnet utente di svuotare il flusso di dati di output del server:
(1) Inviare AO dopo IP.
Questo farà sì che l'host server invii un segnale «svuota-output-bufferizzato» al suo sistema operativo. Tuttavia, l'AO potrebbe non avere effetto localmente, cioè fermare l'output del terminale sul lato Telnet utente, fino a quando il server Telnet non ha ricevuto e processato l'AO e ha inviato indietro un «Synch».
(2) Inviare DO TIMING-MARK [TELNET:7] dopo IP, e scartare tutto l'output localmente fino a quando non viene ricevuto un WILL/WONT TIMING-MARK dal server Telnet.
Poiché il DO TIMING-MARK sarà processato dopo l'IP al server, la risposta dovrebbe essere nel posto giusto nel flusso di dati di output. Tuttavia, il TIMING-MARK non invierà un segnale «svuota output bufferizzato» al sistema operativo del server. Se questo è necessario o meno dipende dal sistema server.
(3) Fare entrambe le cose.
Il metodo migliore non è del tutto chiaro, poiché deve soddisfare un certo numero di host server esistenti che non seguono gli standard Telnet in vari modi. L'approccio più sicuro è probabilmente fornire un'opzione controllabile dall'utente per selezionare (1), (2) o (3).
3.2.5 Stampante e tastiera NVT: RFC-854, p. 11
In modalità NVT, un Telnet non dovrebbe (SHOULD NOT) inviare caratteri con il bit di ordine superiore 1, e non deve (MUST NOT) inviarlo come bit di parità. Le implementazioni che passano il bit di ordine superiore alle applicazioni dovrebbero (SHOULD) negoziare la modalità binaria (vedere Sezione 3.2.6).
DISCUSSIONE:
Gli implementatori dovrebbero essere consapevoli che una lettura rigorosa di RFC-854 consente a un client o server che si aspetta NVT ASCII di ignorare i caratteri con il bit di ordine superiore impostato. In generale, la modalità binaria è prevista per essere utilizzata per la trasmissione di un set di caratteri esteso (oltre 7 bit) con Telnet.
3.2.6 Struttura dei comandi Telnet: RFC-854, p. 13
Poiché le opzioni possono apparire in qualsiasi punto del flusso di dati, un carattere di escape Telnet (noto come IAC, con il valore 255) da inviare come dati deve (MUST) essere raddoppiato.
3.2.7 Opzione binaria Telnet: RFC-856
Quando l'opzione binaria è stata negoziata con successo, sono consentiti caratteri arbitrari a 8 bit. Tuttavia, il flusso di dati deve (MUST) ancora essere scansionato per i caratteri IAC, tutti i comandi Telnet incorporati devono (MUST) essere obbediti, e i byte di dati uguali a IAC devono (MUST) essere raddoppiati. Nessun'altra elaborazione di caratteri (ad esempio sostituire CR con CR NUL o con CR LF) deve (MUST NOT) essere eseguita. In particolare, non c'è convenzione di fine riga (vedere Sezione 3.3.1) in modalità binaria.
3.2.8 Opzione Terminal-Type di Telnet: RFC-1091
L'opzione Terminal-Type deve (MUST) utilizzare i nomi dei tipi di terminale ufficialmente definiti nell'RFC dei numeri assegnati [INTRO:5], quando sono disponibili per il particolare terminale. Tuttavia, il ricevitore di un'opzione Terminal-Type deve (MUST) accettare qualsiasi nome.
3.3 PROBLEMI SPECIFICI
3.3.1 Convenzione di fine riga Telnet
Il protocollo Telnet definisce la sequenza CR LF per significare «fine riga». Per l'input del terminale, questo corrisponde a un tasto di completamento comando o «fine riga» premuto su un terminale utente; su un terminale ASCII, questo è il tasto CR, ma può anche essere etichettato «Return» o «Enter».
Quando un server Telnet riceve la sequenza di fine riga Telnet CR LF come input da un terminale remoto, l'effetto deve (MUST) essere lo stesso come se l'utente avesse premuto il tasto «fine riga» su un terminale locale. Su host server che utilizzano ASCII, in particolare, la ricezione della sequenza Telnet CR LF deve causare lo stesso effetto di un utente locale che preme il tasto CR su un terminale locale. Quindi, CR LF e CR NUL devono (MUST) avere lo stesso effetto su un host server ASCII quando ricevuti come input su una connessione Telnet.
Un Telnet utente deve (MUST) essere in grado di inviare una qualsiasi delle forme: CR LF, CR NUL e LF. Un Telnet utente su un host ASCII dovrebbe (SHOULD) avere una modalità controllabile dall'utente per inviare CR LF o CR NUL quando l'utente preme il tasto «fine riga», e CR LF dovrebbe (SHOULD) essere il predefinito.
3.3.2 Terminali di immissione dati
Oltre ai terminali ASCII orientati alla riga e orientati ai caratteri per i quali è stato progettato Telnet, ci sono diverse famiglie di terminali video che sono talvolta conosciuti come «terminali di immissione dati» o DET. La famiglia IBM 3270 è un esempio ben noto.
3.3.3 Requisiti delle opzioni
Ogni implementazione Telnet deve (MUST) supportare l'opzione binaria [TELNET:3] e l'opzione Suppress Go Ahead [TELNET:5], e dovrebbe (SHOULD) supportare le opzioni Echo [TELNET:4], Status [TELNET:6], End-of-Record [TELNET:9] e Extended Options List [TELNET:8].
Un Telnet utente o server dovrebbe (SHOULD) supportare l'opzione Window Size [TELNET:12] se il sistema operativo locale fornisce la capacità corrispondente.
3.3.4 Iniziazione delle opzioni
Quando il protocollo Telnet viene utilizzato in una situazione client/server, il server dovrebbe (SHOULD) iniziare la negoziazione della modalità di interazione del terminale che si aspetta.
3.3.5 Opzione Linemode di Telnet
Un'importante nuova opzione Telnet, LINEMODE [TELNET:12], è stata proposta. L'opzione LINEMODE fornisce un metodo standard per un Telnet utente e un server Telnet per concordare che il client piuttosto che il server eseguirà l'elaborazione dei caratteri del terminale.
3.4 INTERFACCIA TELNET/UTENTE
3.4.1 Trasparenza del set di caratteri
Le implementazioni Telnet utente dovrebbero (SHOULD) essere in grado di inviare o ricevere qualsiasi carattere ASCII a 7 bit. Dove possibile, qualsiasi interpretazione di caratteri speciali da parte del sistema operativo dell'host utente dovrebbe (SHOULD) essere bypassata in modo che questi caratteri possano essere comodamente inviati e ricevuti sulla connessione.
Un certo valore di carattere deve (MUST) essere riservato come «escape alla modalità comando»; convenzionalmente, raddoppiare questo carattere consente di inserirlo come dati. Il carattere specifico utilizzato dovrebbe (SHOULD) essere selezionabile dall'utente.
3.4.2 Comandi Telnet
Un programma Telnet utente deve (MUST) fornire all'utente la capacità di inserire una qualsiasi delle funzioni di controllo Telnet IP, AO o AYT, e dovrebbe (SHOULD) fornire la capacità di inserire EC, EL e Break.
3.4.3 Errori di connessione TCP
Un programma Telnet utente dovrebbe (SHOULD) segnalare all'utente qualsiasi errore TCP segnalato dal livello di trasporto.
3.4.4 Porta di contatto Telnet non predefinita
Un programma Telnet utente dovrebbe (SHOULD) consentire all'utente di specificare opzionalmente un numero di porta di contatto non standard sull'host server Telnet.
3.4.5 Svuotamento dell'output
Un programma Telnet utente dovrebbe (SHOULD) fornire all'utente la capacità di specificare se l'output deve essere svuotato o meno quando viene inviato un IP; vedere Sezione 3.2.4.
3.5 RIEPILOGO DEI REQUISITI TELNET
| Funzionalità | Sezione | MUST | SHOULD | MAY | SHOULD NOT | MUST NOT |
|---|---|---|---|---|---|---|
| Negoziazione delle opzioni | ||||||
| Implementare negoziazione opzioni | 3.2.1 | ✓ | ||||
| Evitare loop di negoziazione | 3.2.1 | ✓ | ||||
| Rifiutare opzioni non supportate | 3.2.1 | ✓ | ||||
| Negoziazione OK in qualsiasi momento | 3.2.1 | ✓ | ||||
| Predefinito su NVT | 3.2.1 | ✓ | ||||
| Inviare nome ufficiale in Term-Type | 3.2.8 | ✓ | ||||
| Accettare qualsiasi nome in Term-Type | 3.2.8 | ✓ | ||||
| Implementare Binary, Suppress-GA | 3.3.3 | ✓ | ||||
| Opzioni Echo, Status, EOL, Ext-Opt-List | 3.3.3 | ✓ | ||||
| Opzione Window-Size se appropriato | 3.3.3 | ✓ | ||||
| Server inizia negoziazioni di modalità | 3.3.4 | ✓ | ||||
| Funzioni di controllo | ||||||
| Supportare SE NOP DM IP AO AYT SB | 3.2.3 | ✓ | ||||
| Supportare EOR EC EL Break | 3.2.3 | ✓ | ||||
| Ignorare funzioni non supportate | 3.2.3 | ✓ | ||||
| Scartare dati urgenti fino a DM | 3.2.4 | ✓ | ||||
| Codifica | ||||||
| Non inviare bit alto in NVT | 3.2.5 | ✓ | ||||
| Non inviare bit alto come parità | 3.2.5 | ✓ | ||||
| Raddoppiare sempre byte IAC | 3.2.6 | ✓ | ||||
| Raddoppiare IAC in modalità binaria | 3.2.7 | ✓ | ||||
| Fine riga | ||||||
| EOL al server = fine riga locale | 3.3.1 | ✓ | ||||
| Server ASCII accetta CR LF o CR NUL | 3.3.1 | ✓ | ||||
| Utente può inviare CR LF, CR NUL, LF | 3.3.1 | ✓ | ||||
| Utente ASCII può selezionare CR LF/CR NUL | 3.3.1 | ✓ | ||||
| Modalità predefinita utente è CR LF | 3.3.1 | ✓ | ||||
| Interfaccia utente Telnet | ||||||
| I/O di tutti i caratteri a 7 bit | 3.4.1 | ✓ | ||||
| Bypassare interpretazione OS locale | 3.4.1 | ✓ | ||||
| Carattere di escape | 3.4.1 | ✓ | ||||
| Carattere di escape impostabile dall'utente | 3.4.1 | ✓ | ||||
| Può inserire IP, AO, AYT | 3.4.2 | ✓ | ||||
| Può inserire EC, EL, Break | 3.4.2 | ✓ | ||||
| Segnalare errori TCP all'utente | 3.4.3 | ✓ | ||||
| Porta di contatto non predefinita | 3.4.4 | ✓ | ||||
| Specificare svuotamento output all'invio IP | 3.4.5 | ✓ | ||||
| Ripristinare manualmente modalità output | 3.4.5 | ✓ |