ietf-corpus

rfc-1123

Requirements for Internet Hosts - Application and Support

R. Braden (Editor)
date1989-10 streamLegacy statusINTERNET STANDARD pages98 canonicalhttps://www.rfc-editor.org/rfc/rfc1123 doi10.17487/RFC1123 errataview
This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]

updated by

updates

also

Extracted elements (26)

design-rationale §1.2.4

Configurable parameters are required throughout the stack because values depend on external factors, specifications may evolve, and some configurations are needed to coexist with faulty implementations. Default values MUST implement the official protocol rather than mis-configurations accommodating broken peers.

design-rationale §3.3.1

RFC-854's ambiguity about whether to send CR LF or CR NUL for the end-of-line key caused massive and continuing interoperability failures. Some User Telnets send CR LF, others CR NUL; RFC-1123 resolves this by requiring ASCII servers to accept both forms as equivalent end-of-line.

tcp

design-rationale §1.2.2

The Robustness Principle states: 'Be liberal in what you accept, and conservative in what you send.' Software must deal with every conceivable error and must not fail on undefined or unknown protocol values (e.g., an unknown error code); enumerations in specifications must be assumed incomplete.

security

interoperability-note §4.1.3.1 SHOULD

FTP allows experimental commands prefixed with 'X'. All implementations SHOULD recognize both the RFC-959 forms and the legacy 'X' forms of directory commands (XMKD/MKD, XRMD/RMD, XPWD/PWD, XCUP/CDUP, XCWD/CWD), because deployed servers may only support one form.

tcp

interoperability-note §4.2.3.1

TFTP's Sorcerer's Apprentice Syndrome: when a DATA packet is delayed and the sender retransmits, the receiver ACKs both copies, which causes the sender to send two copies of the next block — doubling all subsequent packets for the rest of the transfer. Correct TFTP implementations must not retransmit on receiving a duplicate ACK.

udp

normative-requirement §4.1.2.6 MUST

A server-FTP MUST implement the PASV command. A new PASV MUST be issued before each transfer command when conducting multiple third-party transfers in the same session. The 227 reply format is non-standard; client must scan for the first digit of host and port numbers.

tcp

normative-requirement §4.1.2.9 MUST

A Server-FTP MUST return the actual unique file name in the 125 or 150 reply to STOU, in the format '125 FILE: pppp' or '150 FILE: pppp'. The 250 reply code mentioned in RFC-959 for STOU is incorrect.

tcp

normative-requirement §4.1.2.11 MUST

A Server-FTP MUST send only correctly formatted replies. A User-FTP SHOULD use only the highest-order digit of a 3-digit reply code for procedural decisions, and MUST handle multi-line replies. A Server SHOULD send 4xx (temporary failure) when a retry might succeed.

tcp

normative-requirement §3.2.6 MUST

A Telnet IAC byte (value 255) to be sent as data MUST be doubled. In Binary mode, the stream MUST still be scanned for IAC; embedded Telnet commands MUST be obeyed; IAC data bytes MUST be doubled; and CR/end-of-line processing MUST NOT be performed.

tcp

normative-requirement §3.2.2 MUST

A Telnet Server that never sends Go Ahead MUST negotiate the Suppress Go Ahead option. Both User and Server Telnet MUST always accept Suppress Go Ahead negotiation, allowing either end to veto use of GA commands.

tcp

normative-requirement §4.1.2.12 MUST NOT

A User-FTP MUST NOT send Telnet controls other than SYNCH and IP on the FTP control connection and MUST NOT attempt Telnet option negotiation. A server-FTP MUST be capable of accepting and refusing Telnet option negotiations (DONT/WONT). On multihomed servers, the data port MUST share the same local IP as the control connection.

tcp, ip

normative-requirement §4.1.2.5 SHOULD

A User-FTP using STREAM mode SHOULD send a PORT command to assign a non-default data port before each transfer command, because TIME-WAIT delays prevent immediate socket-pair reuse across multiple transfers in a single session.

tcp

normative-requirement §4.1.2.1 MUST

An FTP program MUST support TYPE I (IMAGE/binary) and TYPE L 8 (LOCAL type with logical byte size 8). Implementation of page structure is NOT RECOMMENDED; if a host requires it for 'holey' files, it MUST use the defined page structure format.

tcp

normative-requirement §2.3 SHOULD

Application implementations SHOULD try multiple addresses returned for a multihomed remote host until success is obtained. A UDP server SHOULD send replies using the same IP source address as the specific destination address of the request.

ip, udp

normative-requirement §2.4 MUST

Applications MUST select appropriate TOS values when invoking transport layer services, and these values MUST be configurable. The two currently unused TOS bits MUST be zero.

ip

normative-requirement §2.2 MUST

Applications using DNS MUST cope with soft error conditions, MUST wait a reasonable interval between successive retries on soft error, and MUST allow for the possibility that network problems may deny DNS service for hours or even days.

dns

normative-requirement §3.2.3 MUST

Both User and Server Telnets MUST support the control functions AO, AYT, DM, IP, NOP, SB, and SE. A host MUST be able to receive and ignore any Telnet control function it does not support.

tcp

normative-requirement §4.1.2.7 MUST

Data returned by NLST MUST contain only a simple list of legal pathnames usable directly as arguments to subsequent transfer commands. LIST and NLST SHOULD use implied TYPE AN (or TYPE EN for EBCDIC).

tcp

normative-requirement §3.2.1 MUST

Every Telnet implementation MUST include option negotiation and subnegotiation machinery, MUST carefully follow RFC-854 to avoid negotiation loops, MUST refuse unsupported options with WONT/DONT, and MUST default to and support NVT if all option negotiations fail.

tcp

normative-requirement §3.3.3 MUST

Every Telnet implementation MUST support the Binary option and the Suppress Go Ahead option, and SHOULD support Echo, Status, End-of-Record, and Extended Options List options. A server SHOULD initiate negotiation of the terminal interaction mode it expects.

tcp

normative-requirement §2.1 MUST

Host software MUST support host names beginning with a digit (relaxing RFC-952), MUST handle names up to 63 characters, and SHOULD handle up to 255 characters. User input SHOULD be checked syntactically for dotted-decimal form before DNS lookup.

dns

normative-requirement §4.1.2.10 MUST NOT

Implementors MUST NOT assume any correspondence between READ boundaries on the FTP control connection and Telnet EOL sequences (CR LF); a server or client must continue reading until a complete CR LF is found before processing a command. A single READ may include more than one FTP command.

tcp

normative-requirement §3.3.1 MUST

The Telnet end-of-line sequence CR LF MUST be used for non-interactive data (e.g., server output or Telnet incorporated into another protocol). An ASCII server MUST treat both CR LF and CR NUL equivalently as end-of-line on input. A User Telnet MUST be able to send CR LF, CR NUL, and LF.

tcp

normative-requirement §3.2.4 MUST

When receiving TCP urgent data, a Telnet implementation MUST discard all data except Telnet commands until the DM byte and end-of-urgent is reached. When a Server Telnet receives AO, it MUST send a Telnet Synch sequence back to the user to flush the output stream.

tcp

protocol-element §4.1.2.13

FTP minimum implementation requires: TYPE ASCII Non-print, IMAGE, LOCAL 8; MODE Stream; STRUCTURE File and Record (if OS supports it); and commands USER, PASS, ACCT, PORT, PASV, TYPE, MODE, STRU, RETR, STOR, APPE, RNFR, RNTO, DELE, CWD, CDUP, RMD, MKD, PWD, LIST, NLST, SYST, STAT, HELP, NOOP, QUIT.

tcp

security-consideration §1.2.2

Host software should assume the network is filled with malevolent entities sending packets designed to have the worst possible effect. Hosts must be prepared not only to survive misbehaving peers but to cooperate in limiting the disruption such hosts can cause to the shared communication facility.

security