From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2217.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc2217.txt (limited to 'doc/rfc/rfc2217.txt') diff --git a/doc/rfc/rfc2217.txt b/doc/rfc/rfc2217.txt new file mode 100644 index 0000000..d99f688 --- /dev/null +++ b/doc/rfc/rfc2217.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group G. Clark +Request for Comments: 2217 Cisco Systems, Inc. +Category: Experimental October 1997 + + + Telnet Com Port Control Option + + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Introduction + + This memo proposes a protocol to allow greater use of modems attached + to a network for outbound dialing purposes. + +Table of Contents + 1. Negotiation of the Com Port + Control Option Protocol .................. 5 + 2. Com Port Configuration Commands .................. 6 + Version + Baud Rate + Data Bit Size + Parity + Stop Bit size + 3. Special Com Port Control Commands ................. 8 + XON/XOFF Flow Control + HARDWARE Flow Control + BREAK Signal + DTR Signal + RTS Signal + 4. Notification of Com Port and .................. 12 + Modem Line Changes + 5. Flow Control .................. 13 + 6. Security Considerations .................. 13 + 7. Author's Address .................. 14 + 8. Reference Section .................. 14 + +Discussion + + The Telnet protocol defines an interactive, character-oriented + communications session. It was originally designed to establish a + session between a client and a remote login service running on a host + [5]. + + + +Clark Experimental [Page 1] + +RFC 2217 Telnet Com Port Control Option October 1997 + + + Many new business functions require a person to connect to remote + services to retrieve or deposit information. By in large, these + remote services are accessed via an async dial up connection. This + new class of functions include: + + - dial up connections to the Internet + - connecting to bulletin boards + - connecting to internal and external databases + - sending and receiving faxes. + + The general nature of this new class of function requires an + interactive, character-oriented communications session via an async + modem. This is typically known as outbound modem dialing. + + To help defer the cost of installing and maintaining additional phone + lines which may be used very little per person, many equipment + manufacturers have added the ability to establish a Telnet session + directly to the outbound ports on many of the most popular access + servers and routers, here after referred to as access servers. + + However, the current Telnet protocol definitions are not sufficient + to fully support this new use. There are three new areas of + functionality which need to be added to the Telnet protocol to + successfully support the needs of outbound modem dialing. These are: + + - The ability for the client to send com port configuration + information to the access server which is connected to the + outbound modem. This is needed to ensure the data being + transmitted and received by the modem is formatted correctly + at the byte level. + + - The ability for the access server to inform the client of any + modem line or signal changes such as RLSD changes (carrier + detect). This information is vital, since many client software + packages use this information to determine if a session with the + remote service has been established. RLSD changes are also + used for signaling in Class I faxing [6]. + + - The ability to manage flow control between the client and + the access server which does not interfere with the flow + control mechanisms used by the session between the client and + the remote service. Unfortunately RFC 1372 "Telnet Remote + Flow Control Option" [2] can not be used for this purpose + because it relies on sending XON/XOFF style characters which + maybe transmitted or received as a normal course of the + client / remote service session. + + + + + +Clark Experimental [Page 2] + +RFC 2217 Telnet Com Port Control Option October 1997 + + + Though this discussion has focused on outbound modem dialing as the + primary use of this protocol, the protocol can also be used for any + serial device attached to an access server. Such devices could be: + + - serial printers + - plotters + - monitoring devices such as pipe line monitors or medical + monitors + - general office equipment such as photo-copiers and cash + registers + +Definition of Terms + + Access Server - Any network device which accepts Telnet sessions + and passes the data received to a com port, and + passes data received from the com port to the client + via the Telnet session. + + Baud Rate - For the purposes of this document, baud rate will + mean the communications of data in bits per second. + + Client - Any network device which initiates a Telnet session + to an access server. + + Outbound - Transmission of data from the modem attached to the + access server to a remote service. + + Inbound - Transmission of data from the remote service to the + modem attached to the access server. + + Remove Service - Any service which accepts dial-up connections, + including fax machines. + + + + + + + + + + + + + + + + + + + +Clark Experimental [Page 3] + +RFC 2217 Telnet Com Port Control Option October 1997 + + +Illustration + + ===================== + | | + | CLIENT |\ + | | \ < ---- Local Area / + ===================== \ Enterprise Network + \ + \ + ============================= + | Telnet Interface | + | | | + | | | + | ACCESS SERVER | | + | | | + | | | + | Com Port Interface | + ============================= + | + | + ================== + | | + | MODEM | + | | + ================== + | + Access to Remote Service | + most commonly Public Switched ----->| + Network | + | + | + ====================== + Could be Internet Service | | + Provider, Bulletin Board | | + or FAX machine | REMOTE SERVICE | + | | + | | + ====================== + + + Command Names and Codes: + COM-PORT-OPTION 44 + + + + + + + + + +Clark Experimental [Page 4] + +RFC 2217 Telnet Com Port Control Option October 1997 + + + Client to Access Server Access Server to Client + SIGNATURE text text + SET-BAUDRATE 1 101 + SET-DATASIZE 2 102 + SET-PARITY 3 103 + SET-STOPSIZE 4 104 + SET-CONTROL 5 105 + NOTIFY-LINESTATE 6 106 + NOTIFY-MODEMSTATE 7 107 + FLOWCONTROL-SUSPEND 8 108 + FLOWCONTROL-RESUME 9 109 + SET-LINESTATE-MASK 10 110 + SET-MODEMSTATE-MASK 11 111 + PURGE-DATA 12 112 + + Discussion: As initially proposed, com port configuration + commands are only sent from the client to the access + server. There is no current vision that the access + server would initiate the use of a com port configuration + command, only the notify commands. However, to allow for + access server initiated com port configurations different + command values have been established. + +1. Negotiation of the Com Port Control Option Protocol + + The negotiation of the com port control option protocol uses the + standard Telnet negotiation protocol mechanism: + + IAC WILL COM-PORT-OPTION + The sender of this command is willing to send com port + control option commands. + IAC WONT COM-PORT-OPTION + The sender of this command refuses to send com port + control option commands. + IAC DO COM-PORT-OPTION + The sender of this command is willing to accept com port + control option commands. + IAC DONT COM-PORT-OPTION + The sender of this command refuses to accept com port control + options commands. + + Typically a client will use WILL and WONT, while an access server + will use DO and DONT. + + + + + + + + +Clark Experimental [Page 5] + +RFC 2217 Telnet Com Port Control Option October 1997 + + +2. Com Port Configuration Commands + + Once DO and WILL have been negotiated, the client may send any of the + following commands. The client can send these commands at any time + and multiple times throughout the Telnet session. Each command + transmitted from the client to the access server must be acknowledged + once the command has been processed by the access server. This + confirmation informs the client of the value set at the access server + after the processing of the command. This acknowledgment is not used + to acknowledge the receipt of the command, which is handled at the + TCP protocol layer. Its purpose is to inform the client of the value + in use, which may be different than the value requested in the + client's command. For example, the client may request a baud rate + higher than the access service can provide. If an acknowledgment is + not received by the client within a reasonable time (such as twice + the delay acknowledgment timer), the client may wish to resend the + command or terminate the session. + + Though the commands may be sent from the client to the access server + in any sequence, there are sequences which may result in invalid + configurations for the com port (for example: EVEN parity is only + valid if the data size is set to less than 8 bits). Thus it is + recommended that commands be issued in the following sequence: + + 1. SET-BAUDRATE + 2. SET-DATASIZE + 3. SET-PARITY + 4. SET-STOPSIZE + + IAC SB COM-PORT-OPTION SIGNATURE IAC SE + This command may be sent by either the client or the access + server to exchange signature information. If the command is + sent without it is a request from the sender to receive + the signature text of the receiver. The text may be a + combination of any characters. There is no structure to the + field. It may contain manufacturer information, version + number information, or any other information desired. If an + IAC character appears in the text it must be translated to + IAC-IAC to avoid conflict with the IAC which terminates + the command. + + IAC SB COM-PORT-OPTION SET-BAUD IAC SE + This command is sent by the client to the access server to set + the baud rate of the com port. The value is four octets (4 bytes). + The value is represented in network standard format. The value + is the baud rate being requested. A special case is the value 0. + If the value is zero the client is requesting the current baud + rate of the com port on the access server. + + + +Clark Experimental [Page 6] + +RFC 2217 Telnet Com Port Control Option October 1997 + + + Discussion: Though baud rates used today form a very sparse space, + and the initial version of the option used an index + based baud rate table, after much discussion with a + number of groups it has been determined that the + actual baud rate should be used. There are two main + reasons. 1) It limits the number of updates to the + option as faster baud rates come into use, + 2) It provides the greatest amount of flexibility + in the selection of the baud rates. + + IAC SB COM-PORT-OPTION SET-DATASIZE IAC SE + This command is sent by the client to the access server to set + the data bit size. The command can also be sent to query the + current data bit size. The value is one octet (byte). The value + is an index into the following value table: + + Value Data Bit Size + 0 Request Current Data Bit Size + 1 Available for Future Use + 2 Available for Future Use + 3 Available for Future Use + 4 Available for Future Use + 5 5 + 6 6 + 7 7 + 8 8 + 9-127 Available for Future Use + + Discussion: There are only eight possible values for the data bit + size, only four have ever been used historically and + only two are commonly used today. The use of the + command-value format is recommended to preserve + consistency with other commands. It also reduces the + number of commands defined in the protocol, and + allows for future expansion. + + IAC SB COM-PORT-OPTION SET-PARITY IAC SE + This command is sent by the client to the access server to set + the parity. The command can also be sent to query the current + parity. The value is one octet (byte). The value is an index into + the following value table: + + Value Parity [1] + 0 Request Current Data Size + 1 NONE + 2 ODD + 3 EVEN + 4 MARK + + + +Clark Experimental [Page 7] + +RFC 2217 Telnet Com Port Control Option October 1997 + + + 5 SPACE + 6-127 Available for Future Use + + Discussion: There are only five possible values for parity + commonly used today. The use of the command-value + format is recommended to preserve consistency with + other commands. + + IAC SB COM-PORT-OPTION SET-STOPSIZE IAC SE + This command is sent by the client to the access server to set + the number of stop bits. The command can also be sent to query + the current stop bit size. The value is one octet (byte). The + value is an index into the following value table: + + Value Stop Bit Size + 0 Request Current Data Size + 1 1 + 2 2 + 3 1.5 + 4-127 Available for Future Use + + Discussion: Stop bit 1.5 is supported by most com port hardware + only if data size is set to 5 bits. It is not + commonly used. + +3. Special Com Port Control Commands + + The client can send this command to the access server at any time + and multiple times throughout the Telnet session. Each command + transmitted from the client to the access server is acknowledged + with a confirmation of the command and the actual value set. The + client should expect a response within a reasonable time (such as + twice the delay acknowledgment timer). The client may wish to + resend any command which is not acknowledged or terminate the + session. + + IAC SB COM-PORT-OPTION SET-CONTROL IAC SE + This command is sent by the client to the access server to set + special com port options. The command can also be sent to query + the current option value. The value is one octet (byte). The + value is an index into the following value table: + + Value Control Commands + 0 Request Com Port Flow Control Setting + (outbound/both) + 1 Use No Flow Control (outbound/both) + 2 Use XON/XOFF Flow Control (outbound/both) + 3 Use HARDWARE Flow Control (outbound/both) + + + +Clark Experimental [Page 8] + +RFC 2217 Telnet Com Port Control Option October 1997 + + + 4 Request BREAK State + 5 Set BREAK State ON + 6 Set BREAK State OFF + 7 Request DTR Signal State + 8 Set DTR Signal State ON + 9 Set DTR Signal State OFF + 10 Request RTS Signal State + 11 Set RTS Signal State ON + 12 Set RTS Signal State OFF + 13 Request Com Port Flow Control Setting (inbound) + 14 Use No Flow Control (inbound) + 15 Use XON/XOFF Flow Control (inbound) + 16 Use HARDWARE Flow Control (inbound) + 17 Use DCD Flow Control (outbound/both) + 18 Use DTR Flow Control (inbound) + 19 Use DSR Flow Control (outbound/both) + 20-127 Available for Future Use + + Discussion: Flow control options were divided into inbound and + outbound to take full advantage of existing + programming interfaces and access server + capabilities. + + Discussion: The outbound values should set flow control for both + outbound and inbound. If inbound is to be, or can + be, set separately it should be done after the + setting of the outbound value. + + Discussion: If the access server is not able to set inbound flow + control differently from the outbound flow control, + it should ignore the inbound flow control commands + and set the flow control option based on the outbound + flow control commands only. + + IAC SB COM-PORT-OPTION SET-LINESTATE-MASK IAC SE + This command is sent by the client to the access server to set a + bit mask for the sending of the NOTIFY-LINESTATE option (see + section 4). When the LINESTATE changes on the access server, the + access server will "AND" the new LINESTATE with the LINESTATE- + MASK. If the result is not zero, the access server will send the + result of the "AND" as the value in a NOTIFY-LINESTATE com port + option. If more than one bit satisfies the LINESTATE-MASK, only + one NOTIFY-LINESTATE, with all the satisfying bits, will be sent + to the client. The SET-LINESTATE-MASK may be any combination of + bits as listed below. These are the same bit values used in the + NOTIFY-LINESTATE option. The SET-LINESTATE-MASK values are based + on the most popular UART (com port control chip) in use [1]. + + + + +Clark Experimental [Page 9] + +RFC 2217 Telnet Com Port Control Option October 1997 + + + Bit Position Value Meaning + 7 128 Time-out Error + 6 64 Transfer Shift Register Empty + 5 32 Transfer Holding Register Empty + 4 16 Break-detect Error + 3 8 Framing Error + 2 4 Parity Error + 1 2 Overrun Error + 0 1 Data Ready + + Discussion: The SET-LINESTATE-MASK value of 0 will prevent the + access server from sending NOTIFY-LINESTATE options + to the client. + + Discussion: The SET-LINESTATE-MASK value of 255 will allow the + access server to send a NOTIFY-LINESTATE option to + the client each time the LINESTATE changes on the + access server. + + Discussion: The initial LINESTATE-MASK at the access server is 0. + + Discussion: The client does not have to send a new + SET-LINESTATE-MASK after receiving a NOTIFY- + LINESTATE. The LINESTATE-MASK on the access server + is retained until set by the client or reset at the + start of a new Telnet session. + + IAC SB COM-PORT-OPTION SET-MODEMSTATE-MASK IAC SE + This command is sent by the client to the access server to set a + bit mask for the sending of the NOTIFY-MODEMSTATE option (see + section 4). When the MODEMSTATE changes on the access server, + the access server will "AND" the new MODEMSTATE with the + MODEMSTATE-MASK. If the result is not zero, the access server + will send the result of the "AND" as the value in a NOTIFY- + MODEMSTATE com port option. If more than one bit satisfies the + MODEMSTATE-MASK, only one NOTIFY-MODEMSTATE, with all the + satisfying bits, will be sent to the client. The SET- + MODEMSTATE-MASK may be any combination of bits as listed below. + These are the same bit values used in the NOTIFY-MODEMSTATE + option. The SET-MODEMSTATE-MASK values are based on the most + popular UART (com port control chip) in use [1]. + + + + + + + + + + +Clark Experimental [Page 10] + +RFC 2217 Telnet Com Port Control Option October 1997 + + + Bit Position Value Meaning + 7 128 Receive Line Signal Detect + (also known as Carrier Detect) + 6 64 Ring Indicator + 5 32 Data-Set-Ready Signal State + 4 16 Clear-To-Send Signal State + 3 8 Delta Receive Line Signal Detect + 2 4 Trailing-edge Ring Detector + 1 2 Delta Data-Set-Ready + 0 1 Delta Clear-To-Send + + Discussion: The SET-MODEMSTATE-MASK value of 0 will prevent the + access server from sending NOTIFY-MODEMSTATE options + to the client. + + Discussion: The SET-MODEMSTATE-MASK value of 255 will allow the + access server to send a NOTIFY-MODEMSTATE option to + the client each time the MODEMSTATE changes on the + access server. + + Discussion: The initial MODEMSTATE-MASK at the access server + is 255. + + Discussion: The client does not have to send a new + SET-MODEMSTATE-MASK after receiving a NOTIFY- + MODEMSTATE. The MODEMSTATE-MASK on the access server + is retained until set by the client or reset at the + start of a new Telnet session. + + IAC SB COM-PORT-OPTION PURGE-DATA IAC SE + This command is sent by the client to the access server to + instruct the access server to immediately clear all data from the + buffer or buffers referenced by the value. The value is one + octet (byte). The value is an index into the following value + table: + + Value Purge Data Buffer + 0 Available for Future Use + 1 Purge access server receive data buffer + 2 Purge access server transmit data buffer + 3 Purge both the access server receive data + buffer and the access server transmit data + buffer + 4-127 Available for Future Use + + + + + + + +Clark Experimental [Page 11] + +RFC 2217 Telnet Com Port Control Option October 1997 + + +4. Notification of Com port and Modem Line Changes + + The access server can send these commands to the client any time + and multiple times throughout the Telnet session. The access + server should send the appropriate command to the client as soon + as the com port or modem line changes occurs. The client does + not issue a response to these commands. + + IAC SB COM-PORT-OPTION NOTIFY-LINESTATE IAC SE + The value is one octet (byte). The value is a bit level + composition made up from the value table below. Multiple bit + values may be set in a single transmission. The values are based + on the most popular UART (com port control chip) in use [1]. + + Bit Position Value Meaning + 7 128 Time-out Error + 6 64 Transfer Shift Register Empty + 5 32 Transfer Holding Register Empty + 4 16 Break-detect Error + 3 8 Framing Error + 2 4 Parity Error + 1 2 Overrun Error + 0 1 Data Ready + + + Discussion: The LINESTATE is the line state of the UART on + the access server. + + IAC SB COM-PORT-OPTION NOTIFY-MODEMSTATE IAC SE + The value is one octet (byte). The value is a bit level + composition made up from the value table below. Multiple bit + values may be set in a single transmission. The values are based + on the most popular UART (com port control chip) in use [1]. + + Bit Position Value Meaning + 7 128 Receive Line Signal Detect + (also known as Carrier Detect) + 6 64 Ring Indicator + 5 32 Data-Set-Ready Signal State + 4 16 Clear-To-Send Signal State + 3 8 Delta Receive Line Signal Detect + 2 4 Trailing-edge Ring Detector + 1 2 Delta Data-Set-Ready + 0 1 Delta Clear-To-Send + + + + + + + +Clark Experimental [Page 12] + +RFC 2217 Telnet Com Port Control Option October 1997 + + +5. Flow Control + + The client and/or access server can send these commands any time and + multiple times throughout the Telnet session. + + IAC SB COM-PORT-OPTION FLOWCONTROL-SUSPEND IAC SE + The sender of this command is requesting that the receiver + suspend transmission of both data and commands until the + FLOWCONTROL-RESUME is transmitted by the sender. + + IAC SB COM-PORT-OPTION FLOWCONTROL-RESUME IAC SE + The sender of this command is requesting that the receiver resume + transmission of both data and commands. + + Discussion: Established Telnet sessions are initially in a + resume state between the client and the access server + and the access server and the client. There is no + need to send the resume command during session + initialization. + + Discussion: Multiple concurrent suspend commands may be sent. + Secondary suspend commands can be ignored. + Transmission will resume with the sending of a single + resume command. + + Discussion: The flow control option is designed to handle client + to access server flow control for the Telnet session. + This option has been added in deference to RFC 1372: + Telnet Remote Flow Control Option [2]. RFC 1372 uses + a simple character XON/XOFF technology to implement + flow control. This can lead to two problems. First, + the flow control characters may be valid data values. + Second, the flow control characters may be used for + end to end flow control (client application to remote + dial up service). + +6. Security Considerations + + There are two security issues to discuss; authentication and + resetting resources. + + Authentication can follow either the Kerberos authentication protocol + established in RFC 1411 [3] or the SPX authentication protocol + established in RFC 1412 [4]. + + Once the Telnet session between the client and the access server has + been terminated, the access server should ensure the connection to + the remote service is disconnected and the com port geometry (baud + + + +Clark Experimental [Page 13] + +RFC 2217 Telnet Com Port Control Option October 1997 + + + rate, data size, stop bits, parity, and flow control) is reset to a + factory or administrator defined configuration. This ensures the com + port is in a known state and ready to receive the next client + session. This will make operations more predicable and avoid + problems which might occur from starting a new session with random + com port configurations. + +7. Author's Address + + Glen Clark, Software Architect + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 96134 + USA + + EMail: glenc@cisco.com + WEB: www.cisco.com + +8. Reference Section + + [1] Joe Campbell. C Programmer's Guide to Serial Communications, + Second Edition. Indianapolis: SAMS Publishing, 1993. 213-224. + + [2] Hedrick, C., and D. Borman, "Telnet Remote Flow Control Option", + RFC 1372, Cray Research, Inc., October 1992. + + [3] Borman, D., "Telnet Authentication: Kerberos Version 4", + RFC 1411, Cray Research, Inc., January 1993. + + [4] Alagappan, K., "Telnet Authentication: SPX", + RFC 1412, Digital Equipment Corporation, January 1993. + + [5] D. E. Comer and David Stevens. Internetworking with TCP/IP, + Volume III. Prentice Hall, 1993. + + [6] Andrew Margolis. The FAX Modem Sourcebook. John Wiley & Sons. + 1995. + + + + + + + + + + + + + + +Clark Experimental [Page 14] + -- cgit v1.2.3