archive-gr.com » GR » T » TEIPIR.GR

Total: 878

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".

  • use DO DON T WILL WON T to establish that both parties understand the option and once this is accomplished a more exotic syntax can be used freely For example a party might send a request to alter establish line length If it is accepted then a different syntax can be used for actually negotiating the line length such a sub negotiation might include fields for minimum allowable maximum allowable and desired line lengths The important concept is that Postel Reynolds Page 3 RFC 854 May 1983 such expanded negotiations should never begin until some prior standard negotiation has established that both parties are capable of parsing the expanded syntax In summary WILL XXX is sent by either party to indicate that party s desire offer to begin performing option XXX DO XXX and DON T XXX being its positive and negative acknowledgments similarly DO XXX is sent to indicate a desire request that the other party i e the recipient of the DO begin performing option XXX WILL XXX and WON T XXX being the positive and negative acknowledgments Since the NVT is what is left when no options are enabled the DON T and WON T responses are guaranteed to leave the connection in a state which both ends can handle Thus all hosts may implement their TELNET processes to be totally unaware of options that are not supported simply returning a rejection to i e refusing any option request that cannot be understood As much as possible the TELNET protocol has been made server user symmetrical so that it easily and naturally covers the user user linking and server server cooperating processes cases It is hoped but not absolutely required that options will further this intent In any case it is explicitly acknowledged that symmetry is an operating principle rather than an ironclad rule A companion document TELNET Option Specifications should be consulted for information about the procedure for establishing new options THE NETWORK VIRTUAL TERMINAL The Network Virtual Terminal NVT is a bi directional character device The NVT has a printer and a keyboard The printer responds to incoming data and the keyboard produces outgoing data which is sent over the TELNET connection and if echoes are desired to the NVT s printer as well Echoes will not be expected to traverse the network although options exist to enable a remote echoing mode of operation no host is required to implement this option The code set is seven bit USASCII in an eight bit field except as modified herein Any code conversion and timing considerations are local problems and do not affect the NVT TRANSMISSION OF DATA Although a TELNET connection through the network is intrinsically full duplex the NVT is to be viewed as a half duplex device operating in a line buffered mode That is unless and until Postel Reynolds Page 4 RFC 854 May 1983 options are negotiated to the contrary the following default conditions pertain to the transmission of data over the TELNET connection 1 Insofar as the availability of local buffer space permits data should be accumulated in the host where it is generated until a complete line of data is ready for transmission or until some locally defined explicit signal to transmit occurs This signal could be generated either by a process or by a human user The motivation for this rule is the high cost to some hosts of processing network input interrupts coupled with the default NVT specification that echoes do not traverse the network Thus it is reasonable to buffer some amount of data at its source Many systems take some processing action at the end of each input line even line printers or card punches frequently tend to work this way so the transmission should be triggered at the end of a line On the other hand a user or process may sometimes find it necessary or desirable to provide data which does not terminate at the end of a line therefore implementers are cautioned to provide methods of locally signaling that all buffered data should be transmitted immediately 2 When a process has completed sending data to an NVT printer and has no queued input from the NVT keyboard for further processing i e when a process at one end of a TELNET connection cannot proceed without input from the other end the process must transmit the TELNET Go Ahead GA command This rule is not intended to require that the TELNET GA command be sent from a terminal at the end of each line since server hosts do not normally require a special signal in addition to end of line or other locally defined characters in order to commence processing Rather the TELNET GA is designed to help a user s local host operate a physically half duplex terminal which has a lockable keyboard such as the IBM 2741 A description of this type of terminal may help to explain the proper use of the GA command The terminal computer connection is always under control of either the user or the computer Neither can unilaterally seize control from the other rather the controlling end must relinguish its control explicitly At the terminal end the hardware is constructed so as to relinquish control each time that a line is terminated i e when the New Line key is typed by the user When this occurs the attached local Postel Reynolds Page 5 RFC 854 May 1983 computer processes the input data decides if output should be generated and if not returns control to the terminal If output should be generated control is retained by the computer until all output has been transmitted The difficulties of using this type of terminal through the network should be obvious The local computer is no longer able to decide whether to retain control after seeing an end of line signal or not this decision can only be made by the remote computer which is processing the data Therefore the TELNET GA command provides a mechanism whereby the remote server computer can signal the local user computer that it is time to pass control to the user of the terminal It should be transmitted at those times and only at those times when the user should be given control of the terminal Note that premature transmission of the GA command may result in the blocking of output since the user is likely to assume that the transmitting system has paused and therefore he will fail to turn the line around manually The foregoing of course does not apply to the user to server direction of communication In this direction GAs may be sent at any time but need not ever be sent Also if the TELNET connection is being used for process to process communication GAs need not be sent in either direction Finally for terminal to terminal communication GAs may be required in neither one or both directions If a host plans to support terminal to terminal communication it is suggested that the host provide the user with a means of manually signaling that it is time for a GA to be sent over the TELNET connection this however is not a requirement on the implementer of a TELNET process Note that the symmetry of the TELNET model requires that there is an NVT at each end of the TELNET connection at least conceptually STANDARD REPRESENTATION OF CONTROL FUNCTIONS As stated in the Introduction to this document the primary goal of the TELNET protocol is the provision of a standard interfacing of terminal devices and terminal oriented processes through the network Early experiences with this type of interconnection have shown that certain functions are implemented by most servers but that the methods of invoking these functions differ widely For a human user who interacts with several server systems these differences are highly frustrating TELNET therefore defines a standard representation for five of these functions as described Postel Reynolds Page 6 RFC 854 May 1983 below These standard representations have standard but not required meanings with the exception that the Interrupt Process IP function may be required by other protocols which use TELNET that is a system which does not provide the function to local users need not provide it to network users and may treat the standard representation for the function as a No operation On the other hand a system which does provide the function to a local user is obliged to provide the same function to a network user who transmits the standard representation for the function Interrupt Process IP Many systems provide a function which suspends interrupts aborts or terminates the operation of a user process This function is frequently used when a user believes his process is in an unending loop or when an unwanted process has been inadvertently activated IP is the standard representation for invoking this function It should be noted by implementers that IP may be required by other protocols which use TELNET and therefore should be implemented if these other protocols are to be supported Abort Output AO Many systems provide a function which allows a process which is generating output to run to completion or to reach the same stopping point it would reach if running to completion but without sending the output to the user s terminal Further this function typically clears any output already produced but not yet actually printed or displayed on the user s terminal AO is the standard representation for invoking this function For example some subsystem might normally accept a user s command send a long text string to the user s terminal in response and finally signal readiness to accept the next command by sending a prompt character preceded by to the user s terminal If the AO were received during the transmission of the text string a reasonable implementation would be to suppress the remainder of the text string but transmit the prompt character and the preceding This is possibly in distinction to the action which might be taken if an IP were received the IP might cause suppression of the text string and an exit from the subsystem It should be noted by server systems which provide this function that there may be buffers external to the system in Postel Reynolds Page 7 RFC 854 May 1983 the network and the user s local host which should be cleared the appropriate way to do this is to transmit the Synch signal described below to the user system Are You There AYT Many systems provide a function which provides the user with some visible e g printable evidence that the system is still up and running This function may be invoked by the user when the system is unexpectedly silent for a long time because of the unanticipated by the user length of a computation an unusually heavy system load etc AYT is the standard representation for invoking this function Erase Character EC Many systems provide a function which deletes the last preceding undeleted character or print position from the stream of data being supplied by the user This function is typically used to edit keyboard input when typing mistakes are made EC is the standard representation for invoking this function NOTE A print position may contain several characters which are the result of overstrikes or of sequences such as BS Erase Line EL Many systems provide a function which deletes all the data in the current line of input This function is typically used to edit keyboard input EL is the standard representation for invoking this function THE TELNET SYNCH SIGNAL Most time sharing systems provide mechanisms which allow a terminal user to regain control of a runaway process the IP and AO functions described above are examples of these mechanisms Such systems when used locally have access to all of the signals supplied by the user whether these are normal characters or special out of band signals such as those supplied by the teletype BREAK key or the IBM 2741 ATTN key This is not necessarily true when terminals are connected to the system through the network the network s flow control mechanisms may cause such a signal to be buffered elsewhere for example in the user s host Postel Reynolds Page 8 RFC 854 May 1983 To counter this problem the TELNET Synch mechanism is introduced A Synch signal consists of a TCP Urgent notification coupled with the TELNET command DATA MARK The Urgent notification which is not subject to the flow control pertaining to the TELNET connection is used to invoke special handling of the data stream by the process which receives it In this mode the data stream is immediately scanned for interesting signals as defined below discarding intervening data The TELNET command DATA MARK DM is the synchronizing mark in the data stream which indicates that any special signal has already occurred and the recipient can return to normal processing of the data stream The Synch is sent via the TCP send operation with the Urgent flag set and the DM as the last or only data octet When several Synchs are sent in rapid succession the Urgent notifications may be merged It is not possible to count Urgents since the number received will be less than or equal the number sent When in normal mode a DM is a no operation when in urgent mode it signals the end of the urgent processing If TCP indicates the end of Urgent data before the DM is found TELNET should continue the special handling of the data stream until the DM is found If TCP indicates more Urgent data after the DM is found it can only be because of a subsequent Synch TELNET should continue the special handling of the data stream until another DM is found Interesting signals are defined to be the TELNET standard representations of IP AO and AYT but not EC or EL the local analogs of these standard representations if any all other TELNET commands other site defined signals which can be acted on without delaying the scan of the data stream Since one effect of the SYNCH mechanism is the discarding of essentially all characters except TELNET commands between the sender of the Synch and its recipient this mechanism is specified as the standard way to clear the data path when that is desired For example if a user at a terminal causes an AO to be transmitted the server which receives the AO if it provides that function at all should return a Synch to the user Finally just as the TCP Urgent notification is needed at the TELNET level as an out of band signal so other protocols which make use of TELNET may require a TELNET command which can be viewed as an out of band signal at a different level Postel Reynolds Page 9 RFC 854 May 1983 By convention the sequence IP Synch is to be used as such a signal For example suppose that some other protocol which uses TELNET defines the character string STOP analogously to the TELNET command AO Imagine that a user of this protocol wishes a server to process the STOP string but the connection is blocked because the server is processing other commands The user should instruct his system to 1 Send the TELNET IP character 2 Send the TELNET SYNC sequence that is Send the Data Mark DM as the only character in a TCP urgent mode send operation 3 Send the character string STOP and 4 Send the other protocol s analog of the TELNET DM if any The user or process acting on his behalf must transmit the TELNET SYNCH sequence of step 2 above to ensure that the TELNET IP gets through to the server s TELNET interpreter The Urgent should wake up the TELNET process the IP should wake up the next higher level process THE NVT PRINTER AND KEYBOARD The NVT printer has an unspecified carriage width and page length and can produce representations of all 95 USASCII graphics codes 32 through 126 Of the 33 USASCII control codes 0 through 31 and 127 and the 128 uncovered codes 128 through 255 the following have specified meaning to the NVT printer NAME CODE MEANING NULL NUL 0 No Operation Line Feed LF 10 Moves the printer to the next print line keeping the same horizontal position Carriage Return CR 13 Moves the printer to the left margin of the current line Postel Reynolds Page 10 RFC 854 May 1983 In addition the following codes shall have defined but not required effects on the NVT printer Neither end of a TELNET connection may assume that the other party will take or will have taken any particular action upon receipt or transmission of these BELL BEL 7 Produces an audible or visible signal which does NOT move the print head Back Space BS 8 Moves the print head one character position towards the left margin Horizontal Tab HT 9 Moves the printer to the next horizontal tab stop It remains unspecified how either party determines or establishes where such tab stops are located Vertical Tab VT 11 Moves the printer to the next vertical tab stop It remains unspecified how either party determines or establishes where such tab stops are located Form Feed FF 12 Moves the printer to the top of the next page keeping the same horizontal position All remaining codes do not cause the NVT printer to take any action The sequence CR LF as defined will cause the NVT to be positioned at the left margin of the next print line as would for example the sequence LF CR However many systems and terminals do not treat CR and LF independently and will have to go to some effort to simulate their effect For example some terminals do not have a CR independent of the LF but on such terminals it

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0854.txt (2016-02-14)
    Open archived version from archive



  • Meanings The meaning of each possible TELNET command relevant to this option should be described Note that for complex options where Postel Reynolds Page 1 RFC 855 May 1983 subnegotiation is required there may be a larger number of possible commands The concept of subnegotiation is described in more detail below Section 3 Default Specification The default assumptions for hosts which do not implement or use the option must be described Section 4 Motivation A detailed explanation of the motivation for inventing a particular option or for choosing a particular form for the option is extremely helpful to those who are not faced or don t realize that they are faced by the problem that the option is designed to solve Section 5 Description or Implementation Rules Merely defining the command meanings and providing a statement of motivation are not always sufficient to insure that two implementations of an option will be able to communicate Therefore a more complete description should be furnished in most cases This description might take the form of text a sample implementation hints to implementers etc A Note on Subnegotiation Some options will require more information to be passed between hosts than a single option code For example any option which requires a parameter is such a case The strategy to be used consists of two steps first both parties agree to discuss the parameter s and second the discussion takes place The first step agreeing to discuss the parameters takes place in the normal manner one party proposes use of the option by sending a DO or WILL followed by the option code and the other party accepts by returning a WILL or DO followed by the option code Once both parties have agreed to use the option subnegotiation takes place by using the

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0855.txt (2016-02-14)
    Open archived version from archive


  • stations on the Ethernet cable originally determined by the routing mechanism Packet Reception When an address resolution packet is received the receiving Ethernet module gives the packet to the Address Resolution module which goes through an algorithm similar to the following Negative conditionals indicate an end of processing and a discarding of the packet Do I have the hardware type in ar hrd Yes almost definitely optionally check the hardware length ar hln Do I speak the protocol in ar pro Yes optionally check the protocol length ar pln Merge flag false If the pair is already in my translation table update the sender hardware address field of the entry with the new information in the packet and set Merge flag to true Am I the target protocol address Yes If Merge flag is false add the triplet to the translation table Is the opcode ares op REQUEST NOW look at the opcode Yes Swap hardware and protocol fields putting the local hardware and protocol addresses in the sender fields Set the ar op field to ares op REPLY Send the packet to the new target hardware address on the same hardware on which the request was received Notice that the triplet is merged into the table before the opcode is looked at This is on the assumption that communcation is bidirectional if A has some reason to talk to B then B will probably have some reason to talk to A Notice also that if an entry already exists for the pair then the new hardware address supersedes the old one Related Issues gives some motivation for this Generalization The ar hrd and ar hln fields allow this protocol and packet format to be used for non 10Mbit Ethernets For the 10Mbit Ethernet takes on the value For other hardware networks the ar pro field may no longer correspond to the Ethernet type field but it should be associated with the protocol whose address resolution is being sought Why is it done this way Periodic broadcasting is definitely not desired Imagine 100 workstations on a single Ethernet each broadcasting address resolution information once per 10 minutes as one possible set of parameters This is one packet every 6 seconds This is almost reasonable but what use is it The workstations aren t generally going to be talking to each other and therefore have 100 useless entries in a table they will be mainly talking to a mainframe file server or bridge but only to a small number of other workstations for interactive conversations for example The protocol described in this paper distributes information as it is needed and only once probably per boot of a machine This format does not allow for more than one resolution to be done in the same packet This is for simplicity If things were multiplexed the packet format would be considerably harder to digest and much of the information could be gratuitous Think of a bridge that talks four protocols telling a workstation all four protocol addresses three of which the workstation will probably never use This format allows the packet buffer to be reused if a reply is generated a reply has the same length as a request and several of the fields are the same The value of the hardware field ar hrd is taken from a list for this purpose Currently the only defined value is for the 10Mbit Ethernet ares hrd Ethernet 1 There has been talk of using this protocol for Packet Radio Networks as well and this will require another value as will other future hardware mediums that wish to use this protocol For the 10Mbit Ethernet the value in the protocol field ar pro is taken from the set ether type This is a natural reuse of the assigned protocol types Combining this with the opcode ar op would effectively halve the number of protocols that can be resolved under this protocol and would make a monitor debugger more complex see Network Monitoring and Debugging below It is hoped that we will never see 32768 protocols but Murphy made some laws which don t allow us to make this assumption In theory the length fields ar hln and ar pln are redundant since the length of a protocol address should be determined by the hardware type found in ar hrd and the protocol type found in ar pro It is included for optional consistency checking and for network monitoring and debugging see below The opcode is to determine if this is a request which may cause a reply or a reply to a previous request 16 bits for this is overkill but a flag field is needed The sender hardware address and sender protocol address are absolutely necessary It is these fields that get put in a translation table The target protocol address is necessary in the request form of the packet so that a machine can determine whether or not to enter the sender information in a table or to send a reply It is not necessarily needed in the reply form if one assumes a reply is only provoked by a request It is included for completeness network monitoring and to simplify the suggested processing algorithm described above which does not look at the opcode until AFTER putting the sender information in a table The target hardware address is included for completeness and network monitoring It has no meaning in the request form since it is this number that the machine is requesting Its meaning in the reply form is the address of the machine making the request In some implementations which do not get to look at the 14 byte ethernet header for example this may save some register shuffling or stack space by sending this field to the hardware driver as the hardware destination address of the packet There are no padding bytes between addresses The packet data should be viewed as a byte stream in which only 3 byte pairs are

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0826.txt (2016-02-14)
    Open archived version from archive


  • receiving the SMTP commands Notice that the forward path and reverse path appear in the SMTP commands and replies but not necessarily in the message That is there is no need for these paths and especially this syntax to appear in the To From CC etc fields of the message header If a server SMTP has accepted the task of relaying the mail and Page 14 Postel RFC 821 August 1982 Simple Mail Transfer Protocol later finds that the forward path is incorrect or that the mail cannot be delivered for whatever reason then it must construct an undeliverable mail notification message and send it to the originator of the undeliverable mail as indicated by the reverse path This notification message must be from the server SMTP at this host Of course server SMTPs should not send notification messages about problems with notification messages One way to prevent loops in error reporting is to specify a null reverse path in the MAIL command of a notification message When such a message is relayed it is permissible to leave the reverse path null A MAIL command with a null reverse path appears as follows MAIL FROM R 250 ok S RCPT TO R 250 ok S DATA R 354 send the mail data end with S Date 23 Oct 81 11 22 33 S From SMTP HOSTY ARPA S To JOE HOSTW ARPA S Subject Mail System Problem S S Sorry JOE your message to SAM HOSTZ ARPA lost S HOSTZ ARPA said this S 550 No Such User S R 250 ok Example 7 Page 16 Postel RFC 821 August 1982 Simple Mail Transfer Protocol 3 7 DOMAINS Domains are a recently introduced concept in the ARPA Internet mail system The use of domains changes the address space from a flat global space of simple character string host names to a hierarchically structured rooted tree of global addresses The host name is replaced by a domain and host designator which is a sequence of domain element strings separated by periods with the understanding that the domain elements are ordered from the most specific to the most general For example USC ISIF ARPA Fred Cambridge UK and PC7 LCS MIT ARPA might be host and domain identifiers Whenever domain names are used in SMTP only the official names are used the use of nicknames or aliases is not allowed Postel Page 17 August 1982 RFC 821 Simple Mail Transfer Protocol 3 8 CHANGING ROLES The TURN command may be used to reverse the roles of the two programs communicating over the transmission channel If program A is currently the sender SMTP and it sends the TURN command and receives an ok reply 250 then program A becomes the receiver SMTP If program B is currently the receiver SMTP and it receives the TURN command and sends an ok reply 250 then program B becomes the sender SMTP To refuse to change roles the receiver sends the 502 reply Please note that this command is optional It would not normally be used in situations where the transmission channel is TCP However when the cost of establishing the transmission channel is high this command may be quite useful For example this command may be useful in supporting be mail exchange using the public switched telephone system as a transmission channel especially if some hosts poll other hosts for mail exchanges Page 18 Postel RFC 821 August 1982 Simple Mail Transfer Protocol 4 THE SMTP SPECIFICATIONS 4 1 SMTP COMMANDS 4 1 1 COMMAND SEMANTICS The SMTP commands define the mail transfer or the mail system function requested by the user SMTP commands are character strings terminated by The command codes themselves are alphabetic characters terminated by if parameters follow and otherwise The syntax of mailboxes must conform to receiver site conventions The SMTP commands are discussed below The SMTP replies are discussed in the Section 4 2 A mail transaction involves several data objects which are communicated as arguments to different commands The reverse path is the argument of the MAIL command the forward path is the argument of the RCPT command and the mail data is the argument of the DATA command These arguments or data objects must be transmitted and held pending the confirmation communicated by the end of mail data indication which finalizes the transaction The model for this is that distinct buffers are provided to hold the types of data objects that is there is a reverse path buffer a forward path buffer and a mail data buffer Specific commands cause information to be appended to a specific buffer or cause one or more buffers to be cleared HELLO HELO This command is used to identify the sender SMTP to the receiver SMTP The argument field contains the host name of the sender SMTP The receiver SMTP identifies itself to the sender SMTP in the connection greeting reply and in the response to this command This command and an OK reply to it confirm that both the sender SMTP and the receiver SMTP are in the initial state that is there is no transaction in progress and all state tables and buffers are cleared Postel Page 19 August 1982 RFC 821 Simple Mail Transfer Protocol MAIL MAIL This command is used to initiate a mail transaction in which the mail data is delivered to one or more mailboxes The argument field contains a reverse path The reverse path consists of an optional list of hosts and the sender mailbox When the list of hosts is present it is a reverse source route and indicates that the mail was relayed through each host on the list the first host in the list was the most recent relay This list is used as a source route to return non delivery notices to the sender As each relay host adds itself to the beginning of the list it must use its name as known in the IPCE to which it is relaying the mail rather than the IPCE from which the mail came if they are different In some types of error reporting messages for example undeliverable mail notifications the reverse path may be null see Example 7 This command clears the reverse path buffer the forward path buffer and the mail data buffer and inserts the reverse path information from this command into the reverse path buffer RECIPIENT RCPT This command is used to identify an individual recipient of the mail data multiple recipients are specified by multiple use of this command The forward path consists of an optional list of hosts and a required destination mailbox When the list of hosts is present it is a source route and indicates that the mail must be relayed to the next host on the list If the receiver SMTP does not implement the relay function it may user the same reply it would for an unknown local user 550 When mail is relayed the relay host must remove itself from the beginning forward path and put itself at the beginning of the reverse path When mail reaches its ultimate destination the forward path contains only a destination mailbox the receiver SMTP inserts it into the destination mailbox in accordance with its host mail conventions Page 20 Postel RFC 821 August 1982 Simple Mail Transfer Protocol For example mail received at relay host A with arguments FROM TO will be relayed on to host B with arguments FROM TO This command causes its forward path argument to be appended to the forward path buffer DATA DATA The receiver treats the lines following the command as mail data from the sender This command causes the mail data from this command to be appended to the mail data buffer The mail data may contain any of the 128 ASCII character codes The mail data is terminated by a line containing only a period that is the character sequence see Section 4 5 2 on Transparency This is the end of mail data indication The end of mail data indication requires that the receiver must now process the stored mail transaction information This processing consumes the information in the reverse path buffer the forward path buffer and the mail data buffer and on the completion of this command these buffers are cleared If the processing is successful the receiver must send an OK reply If the processing fails completely the receiver must send a failure reply When the receiver SMTP accepts a message either for relaying or for final delivery it inserts at the beginning of the mail data a time stamp line The time stamp line indicates the identity of the host that sent the message and the identity of the host that received the message and is inserting this time stamp and the date and time the message was received Relayed messages will have multiple time stamp lines When the receiver SMTP makes the final delivery of a message it inserts at the beginning of the mail data a Postel Page 21 August 1982 RFC 821 Simple Mail Transfer Protocol return path line The return path line preserves the information in the from the MAIL command Here final delivery means the message leaves the SMTP world Normally this would mean it has been delivered to the destination user but in some cases it may be further processed and transmitted by another mail system It is possible for the mailbox in the return path be different from the actual sender s mailbox for example if error responses are to be delivered a special error handling mailbox rather than the message senders The preceding two paragraphs imply that the final mail data will begin with a return path line followed by one or more time stamp lines These lines will be followed by the mail data header and body 2 See Example 8 Special mention is needed of the response and further action required when the processing following the end of mail data indication is partially successful This could arise if after accepting several recipients and the mail data the receiver SMTP finds that the mail data can be successfully delivered to some of the recipients but it cannot be to others for example due to mailbox space allocation problems In such a situation the response to the DATA command must be an OK reply But the receiver SMTP must compose and send an undeliverable mail notification message to the originator of the message Either a single notification which lists all of the recipients that failed to get the message or separate notification messages must be sent for each failed recipient see Example 7 All undeliverable mail notification messages are sent using the MAIL command even if they result from processing a SEND SOML or SAML command Page 22 Postel RFC 821 August 1982 Simple Mail Transfer Protocol Example of Return Path and Received Time Stamps Return Path Received from GHI ARPA by JKL ARPA 27 Oct 81 15 27 39 PST Received from DEF ARPA by GHI ARPA 27 Oct 81 15 15 13 PST Received from ABC ARPA by DEF ARPA 27 Oct 81 15 01 59 PST Date 27 Oct 81 15 01 01 PST From JOE ABC ARPA Subject Improved Mailing System Installed To SAM JKL ARPA This is to inform you that Example 8 SEND SEND This command is used to initiate a mail transaction in which the mail data is delivered to one or more terminals The argument field contains a reverse path This command is successful if the message is delivered to a terminal The reverse path consists of an optional list of hosts and the sender mailbox When the list of hosts is present it is a reverse source route and indicates that the mail was relayed through each host on the list the first host in the list was the most recent relay This list is used as a source route to return non delivery notices to the sender As each relay host adds itself to the beginning of the list it must use its name as known in the IPCE to which it is relaying the mail rather than the IPCE from which the mail came if they are different This command clears the reverse path buffer the forward path buffer and the mail data buffer and inserts the reverse path information from this command into the reverse path buffer SEND OR MAIL SOML This command is used to initiate a mail transaction in which the mail data is delivered to one or more terminals or Postel Page 23 August 1982 RFC 821 Simple Mail Transfer Protocol mailboxes For each recipient the mail data is delivered to the recipient s terminal if the recipient is active on the host and accepting terminal messages otherwise to the recipient s mailbox The argument field contains a reverse path This command is successful if the message is delivered to a terminal or the mailbox The reverse path consists of an optional list of hosts and the sender mailbox When the list of hosts is present it is a reverse source route and indicates that the mail was relayed through each host on the list the first host in the list was the most recent relay This list is used as a source route to return non delivery notices to the sender As each relay host adds itself to the beginning of the list it must use its name as known in the IPCE to which it is relaying the mail rather than the IPCE from which the mail came if they are different This command clears the reverse path buffer the forward path buffer and the mail data buffer and inserts the reverse path information from this command into the reverse path buffer SEND AND MAIL SAML This command is used to initiate a mail transaction in which the mail data is delivered to one or more terminals and mailboxes For each recipient the mail data is delivered to the recipient s terminal if the recipient is active on the host and accepting terminal messages and for all recipients to the recipient s mailbox The argument field contains a reverse path This command is successful if the message is delivered to the mailbox The reverse path consists of an optional list of hosts and the sender mailbox When the list of hosts is present it is a reverse source route and indicates that the mail was relayed through each host on the list the first host in the list was the most recent relay This list is used as a source route to return non delivery notices to the sender As each relay host adds itself to the beginning of the list it must use its name as known in the IPCE to which it is relaying the mail rather than the IPCE from which the mail came if they are different This command clears the reverse path buffer the Page 24 Postel RFC 821 August 1982 Simple Mail Transfer Protocol forward path buffer and the mail data buffer and inserts the reverse path information from this command into the reverse path buffer RESET RSET This command specifies that the current mail transaction is to be aborted Any stored sender recipients and mail data must be discarded and all buffers and state tables cleared The receiver must send an OK reply VERIFY VRFY This command asks the receiver to confirm that the argument identifies a user If it is a user name the full name of the user if known and the fully specified mailbox are returned This command has no effect on any of the reverse path buffer the forward path buffer or the mail data buffer EXPAND EXPN This command asks the receiver to confirm that the argument identifies a mailing list and if so to return the membership of that list The full name of the users if known and the fully specified mailboxes are returned in a multiline reply This command has no effect on any of the reverse path buffer the forward path buffer or the mail data buffer HELP HELP This command causes the receiver to send helpful information to the sender of the HELP command The command may take an argument e g any command name and return more specific information as a response This command has no effect on any of the reverse path buffer the forward path buffer or the mail data buffer Postel Page 25 August 1982 RFC 821 Simple Mail Transfer Protocol NOOP NOOP This command does not affect any parameters or previously entered commands It specifies no action other than that the receiver send an OK reply This command has no effect on any of the reverse path buffer the forward path buffer or the mail data buffer QUIT QUIT This command specifies that the receiver must send an OK reply and then close the transmission channel The receiver should not close the transmission channel until it receives and replies to a QUIT command even if there was an error The sender should not close the transmission channel until it send a QUIT command and receives the reply even if there was an error response to a previous command If the connection is closed prematurely the receiver should act as if a RSET command had been received canceling any pending transaction but not undoing any previously completed transaction the sender should act as if the command or transaction in progress had received a temporary error 4xx TURN TURN This command specifies that the receiver must either 1 send an OK reply and then take on the role of the sender SMTP or 2 send a refusal reply and retain the role of the receiver SMTP If program A is currently the sender SMTP and it sends the TURN command and receives an OK reply 250 then program A becomes the receiver SMTP Program A is then in the initial state as if the transmission channel just opened and it then sends the 220 service ready greeting If program B is currently the receiver SMTP and it receives the TURN command and sends an OK reply 250 then program B becomes the sender SMTP Program B is then in the initial state as if the transmission channel just opened and it then expects to receive the 220 service ready greeting To refuse to change roles the receiver sends the 502 reply Page 26 Postel RFC 821 August 1982 Simple Mail Transfer Protocol There are restrictions on the order in which these command may be used The first command in a session must be the HELO command The HELO command may be used later in a session as well If the HELO command argument is not acceptable a 501 failure reply must be returned and the receiver SMTP must stay in the same state The NOOP HELP EXPN and VRFY commands can be used at any time during a session The MAIL SEND SOML or SAML commands begin a mail transaction Once started a mail transaction consists of one of the transaction beginning commands one or more RCPT commands and a DATA command in that order A mail transaction may be aborted by the RSET command There may be zero or more transactions in a session If the transaction beginning command argument is not acceptable a 501 failure reply must be returned and the receiver SMTP must stay in the same state If the commands in a transaction are out of order a 503 failure reply must be returned and the receiver SMTP must stay in the same state The last command in a session must be the QUIT command The QUIT command can not be used at any other time in a session 4 1 2 COMMAND SYNTAX The commands consist of a command code followed by an argument field Command codes are four alphabetic characters Upper and lower case alphabetic characters are to be treated identically Thus any of the following may represent the mail command MAIL Mail mail MaIl mAIl This also applies to any symbols representing parameter values such as TO or to for the forward path Command codes and the argument fields are separated by one or more spaces However within the reverse path and forward path arguments case is important In particular in some hosts the user smith is different from the user Smith Postel Page 27 August 1982 RFC 821 Simple Mail Transfer Protocol The argument field consists of a variable length character string ending with the character sequence The receiver is to take no action until this sequence is received Square brackets denote an optional argument field If the option is not taken the appropriate default is implied Page 28 Postel RFC 821 August 1982 Simple Mail Transfer Protocol The following are the SMTP commands HELO MAIL FROM RCPT TO DATA RSET SEND FROM SOML FROM SAML FROM VRFY EXPN HELP NOOP QUIT TURN Postel Page 29 August 1982 RFC 821 Simple Mail Transfer Protocol The syntax of the above argument fields using BNF notation where applicable is given below The notation indicates that a field may be repeated one or more times Page 30 Postel RFC 821 August 1982 Simple Mail Transfer Protocol the carriage return character ASCII code 13 the line feed character ASCII code 10 the space character ASCII code 32 one two or three digits representing a decimal integer value in the range 0 through 255 any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case any one of the 128 ASCII characters but not any or any one of the ten digits 0 through 9 any one of the 128 ASCII characters except quote or backslash any one of the 128 ASCII characters no exceptions the control characters ASCII codes 0 through 31 inclusive and 127 Note that the backslash is a quote character which is used to indicate that the next character is to be used literally instead of its normal interpretation For example Joe Smith could be used to indicate a single nine character user field with comma being the fourth character of the field Hosts are generally known by names which are translated to addresses in each host Note that the name elements of domains are the official names no use of nicknames or aliases is allowed Sometimes a host is not known to the translation function and communication is blocked To bypass this barrier two numeric forms are also allowed for host names One form is a decimal integer prefixed by a pound sign which indicates the number is the address of the host Another form is four small decimal integers separated by dots and enclosed by brackets e g 123 255 37 2 which indicates a 32 bit ARPA Internet Address in four 8 bit fields Postel Page 31 August 1982 RFC 821 Simple Mail Transfer Protocol The time stamp line and the return path line are formally defined as follows Return Path Received FROM BY VIA WITH ID FOR The standard names for links are registered with the Network Information Center The standard names for protocols are registered with the Network Information Center the one or two decimal integer day of the month in the range 1 to 31 JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC the two decimal integer year of the century in the range 00 to 99 Page 32 Postel RFC 821 August 1982 Simple Mail Transfer Protocol the two decimal integer hour of the day in the range 00 to 24 the two decimal integer minute of the hour in the range 00 to 59 the two decimal integer second of the minute in the range 00 to 59 UT for Universal Time the default or other time zone designator as in 2 Return Path Example Return Path Example 9 Time Stamp Line Example Received FROM ABC ARPA BY XYZ ARPA 22 OCT 81 09 23 59 PDT Received from ABC ARPA by XYZ ARPA via TELENET with X25 id M12345 for Smith PDQ ARPA 22 OCT 81 09 23 59 PDT Example 10 Postel Page 33 August 1982 RFC 821 Simple Mail Transfer Protocol 4 2 SMTP REPLIES Replies to SMTP commands are devised to ensure the synchronization of requests and actions in the process of mail transfer and to guarantee that the sender SMTP always knows the state of the receiver SMTP Every command must generate exactly one reply The details of the command reply sequence are made explicit in Section 5 3 on Sequencing and Section 5 4 State Diagrams An SMTP reply consists of a three digit number transmitted as three alphanumeric characters followed by some text The number is intended for use by automata to determine what state to enter next the text is meant for the human user It is intended that the three digits contain enough encoded information that the sender SMTP need not examine the text and may either discard it or pass it on to the user as appropriate In particular the text may be receiver dependent and context dependent so there are likely to be varying texts for each reply code A discussion of the theory of reply codes is given in Appendix E Formally a reply is defined to be the sequence a three digit code one line of text and or a multiline reply as defined in Appendix E Only the EXPN and HELP commands are expected to result in multiline replies in normal circumstances however multiline replies are allowed for any command Page 34 Postel RFC 821 August 1982 Simple Mail Transfer Protocol 4 2 1 REPLY CODES BY FUNCTION GROUPS 500 Syntax error command unrecognized This may include errors such as command line too long 501 Syntax error in parameters or arguments 502 Command not implemented 503 Bad sequence of commands 504 Command parameter not implemented 211 System status or system help reply 214 Help message Information on how to use the receiver or the meaning of a particular non standard command this reply is useful only to the human user 220 Service ready 221 Service closing transmission channel 421 Service not available closing transmission channel This may be a reply to any command if the service knows it must shut down 250 Requested mail action okay completed 251 User not local will forward to 450 Requested mail action not taken mailbox unavailable E g mailbox busy 550 Requested action not taken mailbox unavailable E g mailbox not found no access 451 Requested action aborted error in processing 551 User not local please try 452 Requested action not taken insufficient system storage 552 Requested mail action aborted exceeded storage allocation 553 Requested action not taken mailbox name not allowed E g mailbox syntax incorrect 354 Start mail input end with 554 Transaction failed Postel Page 35 August 1982 RFC 821 Simple Mail Transfer Protocol 4 2 2 NUMERIC ORDER LIST OF REPLY CODES 211 System status or system help reply 214 Help message Information on how to use the receiver or the meaning of a particular non standard command this reply is useful only to the human user 220 Service ready 221 Service closing transmission channel 250 Requested mail action okay completed 251 User not local will forward to 354 Start mail input end with 421 Service not available closing transmission channel This may be a reply to any command if the service knows it must shut down 450 Requested mail action not taken mailbox unavailable E g mailbox busy 451 Requested action aborted local error in processing 452 Requested action not taken insufficient system storage 500 Syntax error command unrecognized This may include errors such as command line too long 501 Syntax error in parameters or arguments 502 Command not implemented 503 Bad sequence of commands 504 Command parameter not implemented 550 Requested action not taken mailbox unavailable E g mailbox not found no access 551 User not local please try 552 Requested mail action aborted exceeded storage allocation 553 Requested action not taken mailbox name not allowed E g mailbox syntax incorrect 554 Transaction failed Page 36 Postel RFC 821 August 1982 Simple Mail Transfer Protocol 4 3 SEQUENCING OF COMMANDS AND REPLIES The communication between the sender and receiver is intended to be an alternating dialogue controlled by the sender As such the sender issues a command and the receiver responds with a reply The sender must wait for this response before sending further commands One important reply is the connection greeting Normally a receiver will send a 220 Service ready reply when the connection is completed The sender should wait for this greeting message before sending any commands Note all the greeting type replies have the official name of the server host as the first word following the reply code For example 220 USC ISIF ARPA Service ready The table below lists alternative success and failure replies for each command These must be strictly adhered to a receiver may substitute text in the replies but the meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered COMMAND REPLY SEQUENCES Each command is listed with its possible replies The prefixes used before the possible replies are P for preliminary not used in SMTP I for intermediate S for success F for failure and E for error The 421 reply service not available closing transmission channel may be given to any command if the SMTP receiver knows it must shut down This listing forms the basis for the State Diagrams in Section 4 4 CONNECTION ESTABLISHMENT S 220 F 421 HELO S 250 E 500 501 504 421 MAIL S 250 F 552 451 452 E 500 501 421 Postel Page 37 August 1982 RFC 821 Simple Mail Transfer Protocol RCPT S 250 251 F 550 551 552 553 450 451 452 E 500 501 503 421 DATA I 354 data S 250 F 552 554 451 452 F 451 554 E 500 501 503 421 RSET S 250 E 500 501 504 421 SEND S 250 F 552 451 452 E 500 501 502 421 SOML S 250 F 552 451 452 E 500 501 502 421 SAML S 250 F 552 451 452 E 500 501 502 421 VRFY S 250 251 F 550 551 553 E 500 501 502 504 421 EXPN S 250 F 550 E 500 501 502 504 421 HELP S 211 214 E 500 501 502 504 421 NOOP S 250 E 500 421 QUIT S 221 E 500 TURN S 250 F 502 E 500 503 Page 38 Postel RFC 821 August 1982 Simple Mail Transfer Protocol 4 4 STATE DIAGRAMS Following are state diagrams for a simple minded SMTP implementation Only the first digit of the reply codes is used There is one state diagram for each group of SMTP commands The command groupings were determined by constructing a model for each command and then collecting together the commands with structurally identical models For each command there are three possible outcomes success S failure F and error E In the state diagrams below we use the symbol B for begin and the symbol W for wait for reply First the diagram that represents most of the SMTP commands 1 3 E cmd 2 B W S 4 5 F This diagram models the commands HELO MAIL RCPT RSET SEND SOML SAML VRFY EXPN HELP NOOP QUIT TURN Postel Page 39 August 1982 RFC 821 Simple Mail Transfer Protocol A more complex diagram models the DATA command DATA 1 2 B W E 3 4 5 S V 1 3 2 data W F 4 5 Note that the data here is a series of lines sent from the sender to the receiver with no response expected until the last line is sent Page 40 Postel RFC 821 August 1982 Simple Mail Transfer Protocol 4 5 DETAILS 4 5 1 MINIMUM IMPLEMENTATION In order to make SMTP workable the following minimum implementation is required for all receivers COMMANDS HELO MAIL RCPT DATA RSET NOOP QUIT 4 5 2 TRANSPARENCY Without some provision for data transparency the character sequence ends the mail text and cannot be sent by the user In general users are not aware of such forbidden sequences To allow all user composed text to be transmitted transparently the following procedures are used 1 Before sending a line of mail text the sender SMTP checks the first character of the line If it is a period one additional period is inserted at the beginning of the line 2 When a line of mail text is received by the receiver SMTP it checks the line If the line is composed of a single period it is the end of mail If the first character is a period and there are other characters on the line the first character is deleted The mail data may contain any of the 128 ASCII characters All characters are to be delivered to the recipient s mailbox including format effectors and other control characters If the transmission channel provides an 8 bit byte octets data stream the 7 bit ASCII codes are transmitted right justified in the octets with the high order bits cleared to zero In some systems it may be necessary to transform the data as it is received and stored This may be necessary for hosts that use a different character set than ASCII as their local character set or that store data in records rather than Postel Page 41 August 1982 RFC 821 Simple Mail Transfer Protocol strings If such transforms are necessary they must be reversible especially if such transforms are applied to mail being relayed 4 5 3 SIZES There are several objects that have required minimum maximum sizes That is every implementation must be able to receive objects of at least these sizes but must not send objects larger than these sizes TO THE MAXIMUM EXTENT POSSIBLE IMPLEMENTATION TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH OF THESE OBJECTS SHOULD BE USED user The maximum total length of a user name is 64 characters domain The maximum total length of a domain name or number is 64 characters path The maximum total length of a reverse path or forward path is 256 characters including the punctuation and element separators command line The maximum total length of a command line including the command word and the is 512 characters reply line The maximum total length of a reply line including the reply code and the is 512 characters Page 42 Postel RFC 821 August 1982 Simple Mail Transfer Protocol text line The maximum total length of a text line including the is 1000 characters but not counting the leading dot duplicated for transparency recipients buffer The maximum total number of recipients that must be buffered is 100 recipients TO THE MAXIMUM EXTENT POSSIBLE IMPLEMENTATION TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH OF THESE OBJECTS SHOULD BE USED Errors due to exceeding these limits may be reported by using the reply codes for example 500 Line too long 501 Path too long 552 Too many recipients 552 Too much mail data Postel Page 43 August 1982 RFC 821 Simple Mail Transfer Protocol APPENDIX A TCP Transport service The Transmission Control Protocol 3 is used in the ARPA Internet and in any network following the US DoD standards for internetwork protocols Connection Establishment The SMTP transmission channel is a TCP connection established between the sender process port U and the receiver process port L This single full duplex connection is used as the transmission channel This protocol is assigned the service port 25 31 octal that is L 25 Data Transfer The TCP connection supports the transmission of 8 bit bytes The SMTP data is 7 bit ASCII characters

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0821.txt (2016-02-14)
    Open archived version from archive


  • or after it Writers of mail sending i e header generating programs should realize that there is no network wide definition of the effect of ASCII HT horizontal tab characters on the appear ance of text at another network host therefore the use of tabs in message headers though permitted is discouraged 3 4 3 COMMENTS A comment is a set of ASCII characters which is enclosed in matching parentheses and which is not within a quoted string The comment construct permits message originators to add text which will be useful for human readers but which will be ignored by the formal semantics Comments should be retained while the message is subject to interpretation according to this standard However comments must NOT be included in other cases such as during protocol exchanges with mail servers Comments nest so that if an unquoted left parenthesis occurs in a comment string there must also be a matching right parenthesis When a comment acts as the delimiter between a sequence of two lexical symbols such as two atoms it is lex ically equivalent with a single SPACE for the purposes of regenerating the sequence such as when passing the sequence onto a mail protocol server Comments are detected as such only within field bodies of structured fields If a comment is to be folded onto multiple lines then the syntax for folding must be adhered to See the Lexical August 13 1982 12 RFC 822 Standard for ARPA Internet Text Messages Analysis of Messages section on Folding Long Header Fields above and the section on Case Independence below Note that the official semantics therefore do not see any unquoted CRLFs that are in comments although particular pars ing programs may wish to note their presence For these pro grams it would be reasonable to interpret a CRLF LWSP char as being a CRLF that is part of the comment i e the CRLF is kept and the LWSP char is discarded Quoted CRLFs i e a backslash followed by a CR followed by a LF still must be followed by at least one LWSP char 3 4 4 DELIMITING AND QUOTING CHARACTERS The quote character backslash and characters that delimit syntactic units are not generally to be taken as data that are part of the delimited or quoted unit s In particular the quotation marks that define a quoted string the parentheses that define a comment and the backslash that quotes a following character are NOT part of the quoted string comment or quoted character A quotation mark that is to be part of a quoted string a parenthesis that is to be part of a comment and a backslash that is to be part of either must each be preceded by the quote character backslash Note that the syntax allows any character to be quoted within a quoted string or comment however only certain characters MUST be quoted to be included as data These characters are the ones that are not part of the alternate text group i e ctext or qtext The one exception to this rule is that a single SPACE is assumed to exist between contiguous words in a phrase and this interpretation is independent of the actual number of LWSP chars that the creator places between the words To include more than one SPACE the creator must make the LWSP chars be part of a quoted string Quotation marks that delimit a quoted string and backslashes that quote the following character should NOT accompany the quoted string when the string is passed to processes that do not interpret data according to this specification e g mail protocol servers 3 4 5 QUOTED STRINGS Where permitted i e in words in structured fields quoted strings are treated as a single symbol That is a quoted string is equivalent to an atom syntactically If a quoted string is to be folded onto multiple lines then the syntax for folding must be adhered to See the Lexical Analysis of August 13 1982 13 RFC 822 Standard for ARPA Internet Text Messages Messages section on Folding Long Header Fields above and the section on Case Independence below Therefore the official semantics do not see any bare CRLFs that are in quoted strings however particular parsing programs may wish to note their presence For such programs it would be rea sonable to interpret a CRLF LWSP char as being a CRLF which is part of the quoted string i e the CRLF is kept and the LWSP char is discarded Quoted CRLFs i e a backslash fol lowed by a CR followed by a LF are also subject to rules of folding but the presence of the quoting character backslash explicitly indicates that the CRLF is data to the quoted string Stripping off the first following LWSP char is also appropriate when parsing quoted CRLFs 3 4 6 BRACKETING CHARACTERS There is one type of bracket which must occur in matched pairs and may have pairs nested within each other o Parentheses and are used to indicate com ments There are three types of brackets which must occur in matched pairs and which may NOT be nested o Colon semi colon and are used in address specifications to indicate that the included list of addresses are to be treated as a group o Angle brackets are generally used to indicate the presence of a one machine usable refer ence e g delimiting mailboxes possibly including source routing to the machine o Square brackets and are used to indicate the presence of a domain literal which the appropriate name domain is to use directly bypassing normal name resolution mechanisms 3 4 7 CASE INDEPENDENCE Except as noted alphabetic strings may be represented in any combination of upper and lower case The only syntactic units August 13 1982 14 RFC 822 Standard for ARPA Internet Text Messages which requires preservation of case information are text qtext dtext ctext quoted pair local part except Postmaster When matching any other syntactic unit case is to be ignored For example the field names From FROM from and even FroM are semantically equal and should all be treated ident ically When generating these units any mix of upper and lower case alphabetic characters may be used The case shown in this specification is suggested for message creating processes Note The reserved local part address unit Postmaster is an exception When the value Postmaster is being interpreted it must be accepted in any mixture of case including POSTMASTER and postmaster 3 4 8 FOLDING LONG HEADER FIELDS Each header field may be represented on exactly one line con sisting of the name of the field and its body and terminated by a CRLF this is what the parser sees For readability the field body portion of long header fields may be folded onto multiple lines of the actual field Long is commonly inter preted to mean greater than 65 or 72 characters The former length serves as a limit when the message is to be viewed on most simple terminals which use simple display software how ever the limit is not imposed by this standard Note Some display software often can selectively fold lines to suit the display terminal In such cases sender provided folding can interfere with the display software 3 4 9 BACKSPACE CHARACTERS ASCII BS characters Backspace decimal 8 may be included in texts and quoted strings to effect overstriking However any use of backspaces which effects an overstrike to the left of the beginning of the text or quoted string is prohibited August 13 1982 15 RFC 822 Standard for ARPA Internet Text Messages 3 4 10 NETWORK SPECIFIC TRANSFORMATIONS During transmission through heterogeneous networks it may be necessary to force data to conform to a network s local con ventions For example it may be required that a CR be fol lowed either by LF making a CRLF or by if the CR is to stand alone Such transformations are reversed when the message exits that network When crossing network boundaries the message should be treated as passing through two modules It will enter the first module containing whatever network specific transforma tions that were necessary to permit migration through the current network It then passes through the modules o Transformation Reversal The current network s idiosyncracies are removed and the message is returned to the canonical form speci fied in this standard o Transformation The next network s local idiosyncracies are imposed on the message From Remove Net A Net A idiosyncracies Conformance with standard Impose Net B To idiosyncracies Net B August 13 1982 16 RFC 822 Standard for ARPA Internet Text Messages 4 MESSAGE SPECIFICATION 4 1 SYNTAX Note Due to an artifact of the notational conventions the syn tax indicates that when present some fields must be in a particular order Header fields are NOT required to occur in any particular order except that the message body must occur AFTER the headers It is recommended that if present headers be sent in the order Return Path Received Date From Subject Sender To cc etc This specification permits multiple occurrences of most fields Except as noted their interpretation is not specified here and their use is discouraged The following syntax for the bodies of various fields should be thought of as describing each field body as a single long string or line The Lexical Analysis of Message section on Long Header Fields above indicates how such long strings can be represented on more than one line in the actual transmitted message message fields CRLF text Everything after first null line is message body fields dates Creation time source author id one 1 destination address required optional field others optional source trace net traversals originator original mail resent forwarded trace return path to sender 1 received receipt tags return Return path route addr return address received Received one per relay from domain sending host by domain receiving host via atom physical path with atom link mail protocol id msg id receiver msg id for addr spec initial form August 13 1982 17 RFC 822 Standard for ARPA Internet Text Messages date time time received originator authentic authenticated addr Reply To 1 address authentic From mailbox Single author Sender mailbox Actual submittor From 1 mailbox Multiple authors or not sender resent resent authentic Resent Reply To 1 address resent authentic Resent From mailbox Resent Sender mailbox Resent From 1 mailbox dates orig date Original resent date Forwarded orig date Date date time resent date Resent Date date time destination To 1 address Primary Resent To 1 address cc 1 address Secondary Resent cc 1 address bcc address Blind carbon Resent bcc address optional field Message ID msg id Resent Message ID msg id In Reply To phrase msg id References phrase msg id Keywords phrase Subject text Comments text Encrypted 1 2word extension field To be defined user defined field May be pre empted msg id Unique message id August 13 1982 18 RFC 822 Standard for ARPA Internet Text Messages extension field user defined field 4 2 FORWARDING Some systems permit mail recipients to forward a message retaining the original headers by adding some new fields This standard supports such a service through the Resent prefix to field names Whenever the string Resent begins a field name the field has the same semantics as a field whose name does not have the prefix However the message is assumed to have been forwarded by an original recipient who attached the Resent field This new field is treated as being more recent than the equivalent original field For example the Resent From indicates the person that forwarded the message whereas the From field indi cates the original author Use of such precedence information depends upon partici pants communication needs For example this standard does not dictate when a Resent From address should receive replies in lieu of sending them to the From address Note In general the Resent fields should be treated as con taining a set of information that is independent of the set of original fields Information for one set should not automatically be taken from the other The interpre tation of multiple Resent fields of the same type is undefined In the remainder of this specification occurrence of legal Resent fields are treated identically with the occurrence of August 13 1982 19 RFC 822 Standard for ARPA Internet Text Messages fields whose names do not contain this prefix 4 3 TRACE FIELDS Trace information is used to provide an audit trail of mes sage handling In addition it indicates a route back to the sender of the message The list of known via and with values are registered with the Network Information Center SRI International Menlo Park California 4 3 1 RETURN PATH This field is added by the final transport system that delivers the message to its recipient The field is intended to contain definitive information about the address and route back to the message s originator Note The Reply To field is added by the originator and serves to direct replies whereas the Return Path field is used to identify a path back to the origina tor While the syntax indicates that a route specification is optional every attempt should be made to provide that infor mation in this field 4 3 2 RECEIVED A copy of this field is added by each transport service that relays the message The information in the field can be quite useful for tracing transport problems The names of the sending and receiving hosts and time of receipt may be specified The via parameter may be used to indicate what physical mechanism the message was sent over such as Arpanet or Phonenet and the with parameter may be used to indicate the mail or connection level protocol that was used such as the SMTP mail protocol or X 25 tran sport protocol Note Several with parameters may be included to fully specify the set of protocols that were used Some transport services queue mail the internal message iden tifier that is assigned to the message may be noted using the id parameter When the sending host uses a destination address specification that the receiving host reinterprets by August 13 1982 20 RFC 822 Standard for ARPA Internet Text Messages expansion or transformation the receiving host may wish to record the original specification using the for parameter For example when a copy of mail is sent to the member of a distribution list this parameter may be used to record the original address that was used to specify the list 4 4 ORIGINATOR FIELDS The standard allows only a subset of the combinations possi ble with the From Sender Reply To Resent From Resent Sender and Resent Reply To fields The limitation is intentional 4 4 1 FROM RESENT FROM This field contains the identity of the person s who wished this message to be sent The message creation process should default this field to be a single authenticated machine address indicating the AGENT person system or process entering the message If this is not done the Sender field MUST be present If the From field IS defaulted this way the Sender field is optional and is redundant with the From field In all cases addresses in the From field must be machine usable addr specs and may not contain named lists groups 4 4 2 SENDER RESENT SENDER This field contains the authenticated identity of the AGENT person system or process that sends the message It is intended for use when the sender is not the author of the mes sage or to indicate who among a group of authors actually sent the message If the contents of the Sender field would be completely redundant with the From field then the Sender field need not be present and its use is discouraged though still legal In particular the Sender field MUST be present if it is NOT the same as the From Field The Sender mailbox specification includes a word sequence which must correspond to a specific agent i e a human user or a computer program rather than a standard address This indicates the expectation that the field will identify the single AGENT person system or process responsible for sending the mail and not simply include the name of a mailbox from which the mail was sent For example in the case of a shared login name the name by itself would not be adequate The local part address unit which refers to this agent is expected to be a computer system term and not for example a generalized person reference which can be used outside the network text message context August 13 1982 21 RFC 822 Standard for ARPA Internet Text Messages Since the critical function served by the Sender field is identification of the agent responsible for sending mail and since computer programs cannot be held accountable for their behavior it is strongly recommended that when a computer pro gram generates a message the HUMAN who is responsible for that program be referenced as part of the Sender field mail box specification 4 4 3 REPLY TO RESENT REPLY TO This field provides a general mechanism for indicating any mailbox es to which responses are to be sent Three typical uses for this feature can be distinguished In the first case the author s may not have regular machine based mail boxes and therefore wish es to indicate an alternate machine address In the second case an author may wish additional persons to be made aware of or responsible for replies A somewhat different use may be of some help to text message teleconferencing groups equipped with automatic distribution services include the address of that service in the Reply To field of all messages submitted to the teleconference then participants can reply to conference submissions to guarantee the correct distribution of any submission of their own Note The Return Path field is added by the mail transport service at the time of final deliver It is intended to identify a path back to the orginator of the mes sage The Reply To field is added by the message originator and is intended to direct replies 4 4 4 AUTOMATIC USE OF FROM SENDER REPLY TO For systems which automatically generate address lists for replies to messages the following recommendations are made o The Sender field mailbox should be sent notices of any problems in transport or delivery of the original messages If there is no Sender field then the From field mailbox should be used o The Sender field mailbox should NEVER be used automatically in a recipient s reply message o If the Reply To field exists then the reply should go to the addresses indicated in that field and not to the address es indicated in the From field August 13 1982 22 RFC 822 Standard for ARPA Internet Text Messages o If there is a From field but no Reply To field the reply should be sent to the address es indicated in the From field Sometimes a recipient may actually wish to communicate with the person that initiated the message transfer In such cases it is reasonable to use the Sender address This recommendation is intended only for automated use of originator fields and is not intended to suggest that replies may not also be sent to other recipients of messages It is up to the respective mail handling programs to decide what additional facilities will be provided Examples are provided in Appendix A 4 5 RECEIVER FIELDS 4 5 1 TO RESENT TO This field contains the identity of the primary recipients of the message 4 5 2 CC RESENT CC This field contains the identity of the secondary informa tional recipients of the message 4 5 3 BCC RESENT BCC This field contains the identity of additional recipients of the message The contents of this field are not included in copies of the message sent to the primary and secondary reci pients Some systems may choose to include the text of the Bcc field only in the author s s copy while others may also include it in the text sent to all those indicated in the Bcc list 4 6 REFERENCE FIELDS 4 6 1 MESSAGE ID RESENT MESSAGE ID This field contains a unique identifier the local part address unit which refers to THIS version of THIS message The uniqueness of the message identifier is guaranteed by the host which generates it This identifier is intended to be machine readable and not necessarily meaningful to humans A message identifier pertains to exactly one instantiation of a particular message subsequent revisions to the message should August 13 1982 23 RFC 822 Standard for ARPA Internet Text Messages each receive new message identifiers 4 6 2 IN REPLY TO The contents of this field identify previous correspon dence which this message answers Note that if message iden tifiers are used in this field they must use the msg id specification format 4 6 3 REFERENCES The contents of this field identify other correspondence which this message references Note that if message identif iers are used they must use the msg id specification format 4 6 4 KEYWORDS This field contains keywords or phrases separated by commas 4 7 OTHER FIELDS 4 7 1 SUBJECT This is intended to provide a summary or indicate the nature of the message 4 7 2 COMMENTS Permits adding text comments onto the message without disturbing the contents of the message s body 4 7 3 ENCRYPTED Sometimes data encryption is used to increase the privacy of message contents If the body of a message has been encrypted to keep its contents private the Encrypted field can be used to note the fact and to indicate the nature of the encryption The first parameter indicates the software used to encrypt the body and the second optional is intended to aid the recipient in selecting the proper decryption key This code word may be viewed as an index to a table of keys held by the recipient Note Unfortunately headers must contain envelope as well as contents information Consequently it is neces sary that they remain unencrypted so that mail tran sport services may access them Since names addresses and Subject field contents may contain August 13 1982 24 RFC 822 Standard for ARPA Internet Text Messages sensitive information this requirement limits total message privacy Names of encryption software are registered with the Net work Information Center SRI International Menlo Park Cali fornia 4 7 4 EXTENSION FIELD A limited number of common fields have been defined in this document As network mail requirements dictate addi tional fields may be standardized To provide user defined fields with a measure of safety in name selection such extension fields will never have names that begin with the string X Names of Extension fields are registered with the Network Information Center SRI International Menlo Park California 4 7 5 USER DEFINED FIELD Individual users of network mail are free to define and use additional header fields Such fields must have names which are not already used in the current specification or in any definitions of extension fields and the overall syntax of these user defined fields must conform to this specification s rules for delimiting and folding fields Due to the extension field publishing process the name of a user defined field may be pre empted Note The prefatory string X will never be used in the names of Extension fields This provides user defined fields with a protected set of names August 13 1982 25 RFC 822 Standard for ARPA Internet Text Messages 5 DATE AND TIME SPECIFICATION 5 1 SYNTAX date time day date time dd mm yy hh mm ss zzz day Mon Tue Wed Thu Fri Sat Sun date 1 2DIGIT month 2DIGIT day month year e g 20 Jun 82 month Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec time hour zone ANSI and Military hour 2DIGIT 2DIGIT 2DIGIT 00 00 00 23 59 59 zone UT GMT Universal Time North American UT EST EDT Eastern 5 4 CST CDT Central 6 5 MST MDT Mountain 7 6 PST PDT Pacific 8 7 1ALPHA Military Z UT A 1 J not used M 12 N 1 Y 12 4DIGIT Local differential hours min HHMM 5 2 SEMANTICS If included day of week must be the day implied by the date specification Time zone may be indicated in several ways UT is Univer sal Time formerly called Greenwich Mean Time GMT is per mitted as a reference to Universal Time The military standard uses a single character for each zone Z is Universal Time A indicates one hour earlier and M indicates 12 hours ear lier N is one hour later and Y is 12 hours later The letter J is not used The other remaining two forms are taken from ANSI standard X3 51 1975 One allows explicit indication of the amount of offset from UT the other uses common 3 character strings for indicating time zones in North America August 13 1982 26 RFC 822 Standard for ARPA Internet Text Messages 6 ADDRESS SPECIFICATION 6 1 SYNTAX address mailbox one addressee group named list group phrase mailbox mailbox addr spec simple address phrase route addr name addr spec route addr route 1 domain path relative addr spec local part domain global address local part word word uninterpreted case preserved domain sub domain sub domain sub domain domain ref domain literal domain ref atom symbolic reference 6 2 SEMANTICS A mailbox receives mail It is a conceptual entity which does not necessarily pertain to file storage For example some sites may choose to print mail on their line printer and deliver the output to the addressee s desk A mailbox specification comprises a person system or pro cess name reference a domain dependent string and a name domain reference The name reference is optional and is usually used to indicate the human name of a recipient The name domain refer ence specifies a sequence of sub domains The domain dependent string is uninterpreted except by the final sub domain the rest of the mail service merely transmits it as a literal string 6 2 1 DOMAINS A name domain is a set of registered mail names A name domain specification resolves to a subordinate name domain specification or to a terminal domain dependent string Hence domain specification is extensible permitting any number of registration levels August 13 1982 27 RFC 822 Standard for ARPA Internet Text Messages Name domains model a global logical hierarchical addressing scheme The model is logical in that an address specifica tion is related to name registration and is not necessarily tied to transmission path The model s hierarchy is a directed graph called an in tree such that there is a single path from the root of the tree to any node in the hierarchy If more than one path actually exists they are considered to be different addresses The root node is common to all addresses consequently it is not referenced Its children constitute top level name domains Usually a service has access to its own full domain specification and to the names of all top level name domains The top of the domain addressing hierarchy a child of the root is indicated by the right most field in a domain specification Its child is specified to the left its child to the left and so on Some groups provide formal registration services these con stitute name domains that are independent logically of specific machines In addition networks and machines impli citly compose name domains since their membership usually is registered in name tables In the case of formal registration an organization implements a distributed data base which provides an address to route mapping service for addresses of the form person registry organization Note that organization is a logical entity separate from any particular communication network A mechanism for accessing organization is universally avail able That mechanism in turn seeks an instantiation of the registry its location is not indicated in the address specif ication It is assumed that the system which operates under the name organization knows how to find a subordinate regis try The registry will then use the person string to deter mine where to send the mail specification The latter network oriented case permits simple direct attachment related address specification such as user host network Once the network is accessed it is expected that a message will go directly to the host and that the host will resolve August 13 1982 28 RFC 822 Standard for ARPA Internet Text Messages the user name placing the message in the user s mailbox 6 2 2 ABBREVIATED DOMAIN SPECIFICATION Since any number of levels is possible within the domain hierarchy specification of a fully qualified address can become inconvenient This standard permits abbreviated domain specification in a special case For the address of the sender call the left most sub domain Level N In a header address if all of the sub domains above i e to the right of Level N are the same as those of the sender then they do not have to appear in the specification Otherwise the address must be fully qualified This feature is subject to approval by local sub domains Individual sub domains may require their member systems which originate mail to provide full domain specification only When permitted abbrevia tions may be present only while the message stays within the sub domain of the sender Use of this mechanism requires the sender s sub domain to reserve the names of all top level domains so that full specifications can be distinguished from abbrevi ated specifications For example if a sender s address is sender registry A registry 1 organization X and one recipient s address is recipient registry B registry 1 organization X and another s is recipient registry C registry 2 organization X then registry 1 organization X need not be specified in the the message but registry C registry 2 DOES have to be specified That is the first two addresses may be abbrevi ated but the third address must be fully specified When a message crosses a domain boundary all addresses must be specified in the full format ending with the top level name domain in the right most field It is the responsibility of mail forwarding services to ensure that addresses conform August 13 1982 29 RFC 822 Standard for ARPA Internet Text Messages with this requirement In the case of abbreviated addresses the relaying service must make the necessary expansions It should be noted that it often is difficult for such a service to locate all occurrences of address abbreviations For exam ple it will not be possible to find such abbreviations within the body of the message The Return Path field can aid recipients in recovering from these errors Note When passing any portion of an addr spec onto a process which does not interpret data according to this stan dard e g mail protocol servers There must be NO LWSP chars preceding or following the at sign or any delimiting period such as shown in the above examples and only ONE SPACE between contiguous s 6 2 3 DOMAIN TERMS A domain ref must be THE official name of a registry network or host It is a symbolic reference within a name sub domain At times it is necessary to bypass standard mechan isms for resolving such references using more primitive information such as a network host address rather than its associated host name To permit such references this standard provides the domain literal construct Its contents must conform with the needs of the sub domain in which it is interpreted Domain literals which refer to domains within the ARPA Inter net specify 32 bit Internet addresses in four 8 bit fields noted in decimal as described in Request for Comments 820 Assigned Numbers For example 10 0 3 19 Note THE USE OF DOMAIN LITERALS IS STRONGLY DISCOURAGED It is permitted only as a means of bypassing temporary system limitations such as name tables which are not complete The names of top level domains and the names of domains under in the ARPA Internet are registered with the Network Information Center SRI International Menlo Park California 6 2 4 DOMAIN DEPENDENT LOCAL STRING The local part of an addr spec in a mailbox specification i e the host s name for the mailbox is understood to be August 13 1982 30 RFC 822 Standard for ARPA Internet Text Messages whatever the receiving mail protocol server allows For exam ple some systems do not understand mailbox references of the form P D Q Bach but others do This specification treats periods as lexical separators Hence their presence in local parts which are not quoted strings is detected However such occurrences carry NO semantics That is if a local part has periods within it an address parser will divide the local part into several tokens but the sequence of tokens will be treated as one uninter preted unit The sequence will be re assembled when the address is passed outside of the system such as to a mail pro tocol service For example the address First Last Registry Org is legal and does not require the local part to be surrounded with quotation marks However First Last DOES require quoting The local part of the address when passed outside of the mail system within the Registry Org domain is First Last again without quotation marks 6 2 5 BALANCING LOCAL PART AND DOMAIN In some cases the boundary between local part and domain can be flexible The local part may be a simple string which is used for the final determination of the recipient s mailbox All other levels of reference are therefore part of the domain For some systems in the case of abbreviated reference to the local and subordinate sub domains it may be possible to specify only one reference within the domain part and place the other subordinate name domain references within the local part This would appear as mailbox sub1 sub2 this domain Such a specification would be acceptable to address parsers which conform to RFC 733 but do not support this newer Internet standard While contrary to the intent of this stan dard the form is legal Also some sub domains have a specification syntax which does not conform to this standard For example sub net mailbox sub domain domain August 13 1982 31 RFC 822 Standard for ARPA Internet Text Messages uses a different parsing sequence for local part than for domain Note As a rule the domain specification should contain fields which are encoded according to the syntax of this standard and which contain generally standardized information The local part specification should con tain only that portion of the address which deviates from the form or intention of the domain field 6 2 6 MULTIPLE MAILBOXES An individual may have several mailboxes and wish to receive mail at whatever mailbox is convenient for the sender to access This standard does not provide a means of specifying any member of a list of mailboxes A set of individuals may wish to receive mail as a single unit i e a distribution list The construct permits specification of such a list Recipient mailboxes are speci fied within the bracketed part A copy of the transmitted message is to be sent to each mailbox listed This standard does not permit recursive specification of groups within groups While a list must be named it is not required that the con tents of the list be included In this case the

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0822.txt (2016-02-14)
    Open archived version from archive


  • sent will return an ICMP redirect message to report that there is a better gateway to reach the net in question The arrival of this redirect should cause an update of the local table The number of entries in the local table should be determined by the maximum number of active connections which this particular host can support at any one time For a large time sharing system one might imagine a table with 100 or more entries For a personal computer being used to support a single user telnet connection only one address to gateway association need be maintained at once The above strategy actually does not completely solve the problem but only pushes it down one level where the problem then arises of how a new host freshly arriving on the internet finds all of its accessible gateways Intentionally this problem is not solved within the internetwork architecture The reason is that different networks have drastically different strategies for allowing a host to find out about other hosts on its immediate network Some nets permit a broadcast mechanism In this case a host can send out a message and expect an answer back from all of the attached gateways In other cases where a particular network is richly provided with tools to support the internet there may be a special network mechanism which a host can invoke to determine where the gateways are In other cases it may be necessary for an installer to manually provide the name of at 7 least one accessible gateway Once a host has discovered the name of one gateway it can build up a table of all other available gateways by keeping track of every gateway that has been reported back to it in an ICMP message 5 Advanced Topics in Addressing and Routing The preceding discussion describes the mechanism required in a minimal implementation an implementation intended only to provide operational service access today to the various networks that make up the internet For any host which will participate in future research as contrasted with service some additional features are required These features will also be helpful for service hosts if they wish to obtain access to some of the more exotic networks which will become part of the internet over the next few years All implementors are urged to at least provide a structure into which these features could be later integrated There are several features either already a part of the architecture or now under development which are used to modify or expand the relationships between addresses and routes The IP source route options allow a host to explicitly direct a datagram through a series of gateways to its foreign host An alternative form of the ICMP redirect packet has been proposed which would return information specific to a particular destination host not a destination net Finally additional IP options have been proposed to identify particular routes within the internet that are unacceptable The difficulty with implementing these new features is that the mechanisms do not lie 8 entirely within the bounds of IP All the mechanisms above are designed to apply to a particular connection so that their use must be specified at the TCP level Thus the interface between IP and the layers above it must include mechanisms to allow passing this information back and forth and TCP or any other protocol at this level such as UDP must be prepared to store this information The passing of information between IP and TCP is made more complicated by the fact that some of the information in particular ICMP packets may arrive at any time The normal interface envisioned between TCP and IP is one across which packets can be sent or received The existence of asynchronous ICMP messages implies that there must be an additional channel between the two unrelated to the actual sending and receiving of data In fact there are many other ICMP messages which arrive asynchronously and which must be passed from IP up to higher layers See RFC 816 Fault Isolation and Recovery Source routes are already in use in the internet and many implementations will wish to be able to take advantage of them The following sorts of usages should be permitted First a user when initiating a TCP connection should be able to hand a source route into TCP which in turn must hand the source route to IP with every outgoing datagram The user might initially obtain the source route by querying a different sort of name server which would return a source route instead of an address or the user may have fabricated the source route manually A TCP which is listening for a connection rather than attempting to open one must be prepared to receive a datagram which contains a IP return route in which case it must remember this return route and use it as a source route on all returning datagrams 9 6 Ports and Service Identifiers The IP layer of the architecture contains the address information which specifies the destination host to which the datagram is being sent In fact datagrams are not intended just for particular hosts but for particular agents within a host processes or other entities that are the actual source and sink of the data IP performs only a very simple dispatching once the datagram has arrived at the target host it dispatches it to a particular protocol It is the responsibility of that protocol handler for example TCP to finish dispatching the datagram to the particular connection for which it is destined This next layer of dispatching is done using port identifiers which are a part of the header of the higher level protocol and not the IP layer This two layer dispatching architecture has caused a problem for certain implementations In particular some implementations have wished to put the IP layer within the kernel of the operating system and the TCP layer as a user domain application program Strict

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0814.txt (2016-02-14)
    Open archived version from archive


  • of FIN rcv ACK of FIN rcv FIN Timeout 2MSL x V x V snd ACK delete TCB TIME WAIT CLOSED TCP Connection State Diagram Figure 6 Page 23 September 1981 Transmission Control Protocol Functional Specification 3 3 Sequence Numbers A fundamental notion in the design is that every octet of data sent over a TCP connection has a sequence number Since every octet is sequenced each of them can be acknowledged The acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X have been received This mechanism allows for straight forward duplicate detection in the presence of retransmission Numbering of octets within a segment is that the first data octet immediately following the header is the lowest numbered and the following octets are numbered consecutively It is essential to remember that the actual sequence number space is finite though very large This space ranges from 0 to 2 32 1 Since the space is finite all arithmetic dealing with sequence numbers must be performed modulo 2 32 This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2 32 1 to 0 again There are some subtleties to computer modulo arithmetic so great care should be taken in programming the comparison of such values The symbol 0 RCV NXT 0 0 not acceptable 0 0 RCV NXT B SYN my sequence number is X 2 A B ACK your sequence number is Y Page 27 September 1981 Transmission Control Protocol Functional Specification Because steps 2 and 3 can be combined in a single message this is called the three way or three message handshake A three way handshake is necessary because sequence numbers are not tied to a global clock in the network and TCPs may have different mechanisms for picking the ISN s The receiver of the first SYN has no way of knowing whether the segment was an old delayed one or not unless it remembers the last sequence number used on the connection which is not always possible and so it must ask the sender to verify this SYN The three way handshake and the advantages of a clock driven scheme are discussed in 3 Knowing When to Keep Quiet To be sure that a TCP does not create a segment that carries a sequence number which may be duplicated by an old segment remaining in the network the TCP must keep quiet for a maximum segment lifetime MSL before assigning any sequence numbers upon starting up or recovering from a crash in which memory of sequence numbers in use was lost For this specification the MSL is taken to be 2 minutes This is an engineering choice and may be changed if experience indicates it is desirable to do so Note that if a TCP is reinitialized in some sense yet retains its memory of sequence numbers in use then it need not wait at all it must only be sure to use sequence numbers larger than those recently used The TCP Quiet Time Concept This specification provides that hosts which crash without retaining any knowledge of the last sequence numbers transmitted on each active i e not closed connection shall delay emitting any TCP segments for at least the agreed Maximum Segment Lifetime MSL in the internet system of which the host is a part In the paragraphs below an explanation for this specification is given TCP implementors may violate the quiet time restriction but only at the risk of causing some old data to be accepted as new or new data rejected as old duplicated by some receivers in the internet system TCPs consume sequence number space each time a segment is formed and entered into the network output queue at a source host The duplicate detection and sequencing algorithm in the TCP protocol relies on the unique binding of segment data to sequence space to the extent that sequence numbers will not cycle through all 2 32 values before the segment data bound to those sequence numbers has been delivered and acknowledged by the receiver and all duplicate copies of the segments have drained from the internet Without such an assumption two distinct TCP segments could conceivably be Page 28 September 1981 Transmission Control Protocol Functional Specification assigned the same or overlapping sequence numbers causing confusion at the receiver as to which data is new and which is old Remember that each segment is bound to as many consecutive sequence numbers as there are octets of data in the segment Under normal conditions TCPs keep track of the next sequence number to emit and the oldest awaiting acknowledgment so as to avoid mistakenly using a sequence number over before its first use has been acknowledged This alone does not guarantee that old duplicate data is drained from the net so the sequence space has been made very large to reduce the probability that a wandering duplicate will cause trouble upon arrival At 2 megabits sec it takes 4 5 hours to use up 2 32 octets of sequence space Since the maximum segment lifetime in the net is not likely to exceed a few tens of seconds this is deemed ample protection for foreseeable nets even if data rates escalate to l0 s of megabits sec At 100 megabits sec the cycle time is 5 4 minutes which may be a little short but still within reason The basic duplicate detection and sequencing algorithm in TCP can be defeated however if a source TCP does not have any memory of the sequence numbers it last used on a given connection For example if the TCP were to start all connections with sequence number 0 then upon crashing and restarting a TCP might re form an earlier connection possibly after half open connection resolution and emit packets with sequence numbers identical to or overlapping with packets still in the network which were emitted on an earlier incarnation of the same connection In the absence of knowledge about the sequence numbers used on a particular connection the TCP specification recommends that the source delay for MSL seconds before emitting segments on the connection to allow time for segments from the earlier connection incarnation to drain from the system Even hosts which can remember the time of day and used it to select initial sequence number values are not immune from this problem i e even if time of day is used to select an initial sequence number for each new connection incarnation Suppose for example that a connection is opened starting with sequence number S Suppose that this connection is not used much and that eventually the initial sequence number function ISN t takes on a value equal to the sequence number say S1 of the last segment sent by this TCP on a particular connection Now suppose at this instant the host crashes recovers and establishes a new incarnation of the connection The initial sequence number chosen is S1 ISN t last used sequence number on old incarnation of connection If the recovery occurs quickly enough any old Page 29 September 1981 Transmission Control Protocol Functional Specification duplicates in the net bearing sequence numbers in the neighborhood of S1 may arrive and be treated as new packets by the receiver of the new incarnation of the connection The problem is that the recovering host may not know for how long it crashed nor does it know whether there are still old duplicates in the system from earlier connection incarnations One way to deal with this problem is to deliberately delay emitting segments for one MSL after recovery from a crash this is the quite time specification Hosts which prefer to avoid waiting are willing to risk possible confusion of old and new packets at a given destination may choose not to wait for the quite time Implementors may provide TCP users with the ability to select on a connection by connection basis whether to wait after a crash or may informally implement the quite time for all connections Obviously even where a user selects to wait this is not necessary after the host has been up for at least MSL seconds To summarize every segment emitted occupies one or more sequence numbers in the sequence space the numbers occupied by a segment are busy or in use until MSL seconds have passed upon crashing a block of space time is occupied by the octets of the last emitted segment if a new connection is started too soon and uses any of the sequence numbers in the space time footprint of the last segment of the previous connection incarnation there is a potential sequence number overlap area which could cause confusion at the receiver 3 4 Establishing a connection The three way handshake is the procedure used to establish a connection This procedure normally is initiated by one TCP and responded to by another TCP The procedure also works if two TCP simultaneously initiate the procedure When simultaneous attempt occurs each TCP receives a SYN segment which carries no acknowledgment after it has sent a SYN Of course the arrival of an old duplicate SYN segment can potentially make it appear to the recipient that a simultaneous connection initiation is in progress Proper use of reset segments can disambiguate these cases Several examples of connection initiation follow Although these examples do not show connection synchronization using data carrying segments this is perfectly legitimate so long as the receiving TCP doesn t deliver the data to the user until it is clear the data is valid i e the data must be buffered at the receiver until the connection reaches the ESTABLISHED state The three way handshake reduces the possibility of false connections It is the Page 30 September 1981 Transmission Control Protocol Functional Specification implementation of a trade off between memory and messages to provide information for this checking The simplest three way handshake is shown in figure 7 below The figures should be interpreted in the following way Each line is numbered for reference purposes Right arrows indicate departure of a TCP segment from TCP A to TCP B or arrival of a segment at B from A Left arrows SYN RECEIVED 3 ESTABLISHED ESTABLISHED 5 ESTABLISHED ESTABLISHED Basic 3 Way Handshake for Connection Synchronization Figure 7 In line 2 of figure 7 TCP A begins by sending a SYN segment indicating that it will use sequence numbers starting with sequence number 100 In line 3 TCP B sends a SYN and acknowledges the SYN it received from TCP A Note that the acknowledgment field indicates TCP B is now expecting to hear sequence 101 acknowledging the SYN which occupied sequence 100 At line 4 TCP A responds with an empty segment containing an ACK for TCP B s SYN and in line 5 TCP A sends some data Note that the sequence number of the segment in line 5 is the same as in line 4 because the ACK does not occupy sequence number space if it did we would wind up ACKing ACK s Page 31 September 1981 Transmission Control Protocol Functional Specification Simultaneous initiation is only slightly more complex as is shown in figure 8 Each TCP cycles from CLOSED to SYN SENT to SYN RECEIVED to ESTABLISHED TCP A TCP B 1 CLOSED CLOSED 2 SYN SENT 3 SYN RECEIVED SYN RECEIVED 5 SYN RECEIVED 6 ESTABLISHED ESTABLISHED Simultaneous Connection Synchronization Figure 8 The principle reason for the three way handshake is to prevent old duplicate connection initiations from causing confusion To deal with this a special control message reset has been devised If the receiving TCP is in a non synchronized state i e SYN SENT SYN RECEIVED it returns to LISTEN on receiving an acceptable reset If the TCP is in one of the synchronized states ESTABLISHED FIN WAIT 1 FIN WAIT 2 CLOSE WAIT CLOSING LAST ACK TIME WAIT it aborts the connection and informs its user We discuss this latter case under half open connections below Page 32 September 1981 Transmission Control Protocol Functional Specification TCP A TCP B 1 CLOSED LISTEN 2 SYN SENT 3 duplicate SYN RECEIVED 4 SYN SENT LISTEN 6 SYN RECEIVED 7 SYN SENT ESTABLISHED Recovery from Old Duplicate SYN Figure 9 As a simple example of recovery from old duplicates consider figure 9 At line 3 an old duplicate SYN arrives at TCP B TCP B cannot tell that this is an old duplicate so it responds normally line 4 TCP A detects that the ACK field is incorrect and returns a RST reset with its SEQ field selected to make the segment believable TCP B on receiving the RST returns to the LISTEN state When the original SYN pun intended finally arrives at line 6 the synchronization proceeds normally If the SYN at line 6 had arrived before the RST a more complex exchange might have occurred with RST s sent in both directions Half Open Connections and Other Anomalies An established connection is said to be half open if one of the TCPs has closed or aborted the connection at its end without the knowledge of the other or if the two ends of the connection have become desynchronized owing to a crash that resulted in loss of memory Such connections will automatically become reset if an attempt is made to send data in either direction However half open connections are expected to be unusual and the recovery procedure is mildly involved If at site A the connection no longer exists then an attempt by the Page 33 September 1981 Transmission Control Protocol Functional Specification user at site B to send any data on it will result in the site B TCP receiving a reset control message Such a message indicates to the site B TCP that something is wrong and it is expected to abort the connection Assume that two user processes A and B are communicating with one another when a crash occurs causing loss of memory to A s TCP Depending on the operating system supporting A s TCP it is likely that some error recovery mechanism exists When the TCP is up again A is likely to start again from the beginning or from a recovery point As a result A will probably try to OPEN the connection again or try to SEND on the connection it believes open In the latter case it receives the error message connection not open from the local A s TCP In an attempt to establish the connection A s TCP will send a segment containing SYN This scenario leads to the example shown in figure 10 After TCP A crashes the user attempts to re open the connection TCP B in the meantime thinks the connection is open TCP A TCP B 1 CRASH send 300 receive 100 2 CLOSED ESTABLISHED 3 SYN SENT 4 Abort 6 SYN SENT CLOSED 7 SYN SENT Half Open Connection Discovery Figure 10 When the SYN arrives at line 3 TCP B being in a synchronized state and the incoming segment outside the window responds with an acknowledgment indicating what sequence it next expects to hear ACK 100 TCP A sees that this segment does not acknowledge anything it sent and being unsynchronized sends a reset RST because it has detected a half open connection TCP B aborts at line 5 TCP A will Page 34 September 1981 Transmission Control Protocol Functional Specification continue to try to establish the connection the problem is now reduced to the basic 3 way handshake of figure 7 An interesting alternative case occurs when TCP A crashes and TCP B tries to send data on what it thinks is a synchronized connection This is illustrated in figure 11 In this case the data arriving at TCP A from TCP B line 2 is unacceptable because no such connection exists so TCP A sends a RST The RST is acceptable so TCP B processes it and aborts the connection TCP A TCP B 1 CRASH send 300 receive 100 2 ABORT Active Side Causes Half Open Connection Discovery Figure 11 In figure 12 we find the two TCPs A and B with passive connections waiting for SYN An old duplicate arriving at TCP B line 2 stirs B into action A SYN ACK is returned line 3 and causes TCP A to generate a RST the ACK in line 3 is not acceptable TCP B accepts the reset and returns to its passive LISTEN state TCP A TCP B 1 LISTEN LISTEN 2 SYN RECEIVED 3 return to LISTEN 5 LISTEN LISTEN Old Duplicate SYN Initiates a Reset on two Passive Sockets Figure 12 Page 35 September 1981 Transmission Control Protocol Functional Specification A variety of other cases are possible all of which are accounted for by the following rules for RST generation and processing Reset Generation As a general rule reset RST must be sent whenever a segment arrives which apparently is not intended for the current connection A reset must not be sent if it is not clear that this is the case There are three groups of states 1 If the connection does not exist CLOSED then a reset is sent in response to any incoming segment except another reset In particular SYNs addressed to a non existent connection are rejected by this means If the incoming segment has an ACK field the reset takes its sequence number from the ACK field of the segment otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment The connection remains in the CLOSED state 2 If the connection is in any non synchronized state LISTEN SYN SENT SYN RECEIVED and the incoming segment acknowledges something not yet sent the segment carries an unacceptable ACK or if an incoming segment has a security level or compartment which does not exactly match the level and compartment requested for the connection a reset is sent If our SYN has not been acknowledged and the precedence level of the incoming segment is higher than the precedence level requested then either raise the local precedence level if allowed by the user and the system or send a reset or if the precedence level of the incoming segment is lower than the precedence level requested then continue as if the precedence matched exactly if the remote TCP cannot raise the precedence level to match ours this will be detected in the next segment it sends and the connection will be terminated then If our SYN has been acknowledged perhaps in this incoming segment the precedence level of the incoming segment must match the local precedence level exactly if it does not a reset must be sent If the incoming segment has an ACK field the reset takes its sequence number from the ACK field of the segment otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment The connection remains in the same state Page 36 September 1981 Transmission Control Protocol Functional Specification 3 If the connection is in a synchronized state ESTABLISHED FIN WAIT 1 FIN WAIT 2 CLOSE WAIT CLOSING LAST ACK TIME WAIT any unacceptable segment out of window sequence number or unacceptible acknowledgment number must elicit only an empty acknowledgment segment containing the current send sequence number and an acknowledgment indicating the next sequence number expected to be received and the connection remains in the same state If an incoming segment has a security level or compartment or precedence which does not exactly match the level and compartment and precedence requested for the connection a reset is sent and connection goes to the CLOSED state The reset takes its sequence number from the ACK field of the incoming segment Reset Processing In all states except SYN SENT all reset RST segments are validated by checking their SEQ fields A reset is valid if its sequence number is in the window In the SYN SENT state a RST received in response to an initial SYN the RST is acceptable if the ACK field acknowledges the SYN The receiver of a RST first validates it then changes state If the receiver was in the LISTEN state it ignores it If the receiver was in SYN RECEIVED state and had previously been in the LISTEN state then the receiver returns to the LISTEN state otherwise the receiver aborts the connection and goes to the CLOSED state If the receiver was in any other state it aborts the connection and advises the user and goes to the CLOSED state 3 5 Closing a Connection CLOSE is an operation meaning I have no more data to send The notion of closing a full duplex connection is subject to ambiguous interpretation of course since it may not be obvious how to treat the receiving side of the connection We have chosen to treat CLOSE in a simplex fashion The user who CLOSEs may continue to RECEIVE until he is told that the other side has CLOSED also Thus a program could initiate several SENDs followed by a CLOSE and then continue to RECEIVE until signaled that a RECEIVE failed because the other side has CLOSED We assume that the TCP will signal a user even if no RECEIVEs are outstanding that the other side has closed so the user can terminate his side gracefully A TCP will reliably deliver all buffers SENT before the connection was CLOSED so a user who expects no data in return need only wait to hear the connection was CLOSED successfully to know that all his data was received at the destination TCP Users must keep reading connections they close for sending until the TCP says no more data Page 37 September 1981 Transmission Control Protocol Functional Specification There are essentially three cases 1 The user initiates by telling the TCP to CLOSE the connection 2 The remote TCP initiates by sending a FIN control signal 3 Both users CLOSE simultaneously Case 1 Local user initiates the close In this case a FIN segment can be constructed and placed on the outgoing segment queue No further SENDs from the user will be accepted by the TCP and it enters the FIN WAIT 1 state RECEIVEs are allowed in this state All segments preceding and including FIN will be retransmitted until acknowledged When the other TCP has both acknowledged the FIN and sent a FIN of its own the first TCP can ACK this FIN Note that a TCP receiving a FIN will ACK but not send its own FIN until its user has CLOSED the connection also Case 2 TCP receives a FIN from the network If an unsolicited FIN arrives from the network the receiving TCP can ACK it and tell the user that the connection is closing The user will respond with a CLOSE upon which the TCP can send a FIN to the other TCP after sending any remaining data The TCP then waits until its own FIN is acknowledged whereupon it deletes the connection If an ACK is not forthcoming after the user timeout the connection is aborted and the user is told Case 3 both users close simultaneously A simultaneous CLOSE by users at both ends of a connection causes FIN segments to be exchanged When all segments preceding the FINs have been processed and acknowledged each TCP can ACK the FIN it has received Both will upon receiving these ACKs delete the connection Page 38 September 1981 Transmission Control Protocol Functional Specification TCP A TCP B 1 ESTABLISHED ESTABLISHED 2 Close FIN WAIT 1 CLOSE WAIT 3 FIN WAIT 2 CLOSED 6 2 MSL CLOSED Normal Close Sequence Figure 13 TCP A TCP B 1 ESTABLISHED ESTABLISHED 2 Close Close FIN WAIT 1 FIN WAIT 1 3 CLOSING CLOSING 4 TIME WAIT TIME WAIT 2 MSL 2 MSL CLOSED CLOSED Simultaneous Close Sequence Figure 14 Page 39 September 1981 Transmission Control Protocol Functional Specification 3 6 Precedence and Security The intent is that connection be allowed only between ports operating with exactly the same security and compartment values and at the higher of the precedence level requested by the two ports The precedence and security parameters used in TCP are exactly those defined in the Internet Protocol IP 2 Throughout this TCP specification the term security compartment is intended to indicate the security parameters used in IP including security compartment user group and handling restriction A connection attempt with mismatched security compartment values or a lower precedence value must be rejected by sending a reset Rejecting a connection due to too low a precedence only occurs after an acknowledgment of the SYN has been received Note that TCP modules which operate only at the default value of precedence will still have to check the precedence of incoming segments and possibly raise the precedence level they use on the connection The security paramaters may be used even in a non secure environment the values would indicate unclassified data thus hosts in non secure environments must be prepared to receive the security parameters though they need not send them 3 7 Data Communication Once the connection is established data is communicated by the exchange of segments Because segments may be lost due to errors checksum test failure or network congestion TCP uses retransmission after a timeout to ensure delivery of every segment Duplicate segments may arrive due to network or TCP retransmission As discussed in the section on sequence numbers the TCP performs certain tests on the sequence and acknowledgment numbers in the segments to verify their acceptability The sender of data keeps track of the next sequence number to use in the variable SND NXT The receiver of data keeps track of the next sequence number to expect in the variable RCV NXT The sender of data keeps track of the oldest unacknowledged sequence number in the variable SND UNA If the data flow is momentarily idle and all data sent has been acknowledged then the three variables will be equal When the sender creates a segment and transmits it the sender advances SND NXT When the receiver accepts a segment it advances RCV NXT and sends an acknowledgment When the data sender receives an Page 40 September 1981 Transmission Control Protocol Functional Specification acknowledgment it advances SND UNA The extent to which the values of these variables differ is a measure of the delay in the communication The amount by which the variables are advanced is the length of the data in the segment Note that once in the ESTABLISHED state all segments must carry current acknowledgment information The CLOSE user call implies a push function as does the FIN control flag in an incoming segment Retransmission Timeout Because of the variability of the networks that compose an internetwork system and the wide range of uses of TCP connections the retransmission timeout must be dynamically determined One procedure for determining a retransmission time out is given here as an illustration An Example Retransmission Timeout Procedure Measure the elapsed time between sending a data octet with a particular sequence number and receiving an acknowledgment that covers that sequence number segments sent do not have to match segments received This measured elapsed time is the Round Trip Time RTT Next compute a Smoothed Round Trip Time SRTT as SRTT ALPHA SRTT 1 ALPHA RTT and based on this compute the retransmission timeout RTO as RTO min UBOUND max LBOUND BETA SRTT where UBOUND is an upper bound on the timeout e g 1 minute LBOUND is a lower bound on the timeout e g 1 second ALPHA is a smoothing factor e g 8 to 9 and BETA is a delay variance factor e g 1 3 to 2 0 The Communication of Urgent Information The objective of the TCP urgent mechanism is to allow the sending user to stimulate the receiving user to accept some urgent data and to permit the receiving TCP to indicate to the receiving user when all the currently known urgent data has been received by the user This mechanism permits a point in the data stream to be designated as the end of urgent information Whenever this point is in advance of the receive sequence number RCV NXT at the receiving TCP that TCP must tell the user to go into urgent mode when the receive sequence number catches up to the urgent pointer the TCP must tell user to go Page 41 September 1981 Transmission Control Protocol Functional Specification into normal mode If the urgent pointer is updated while the user is in urgent mode the update will be invisible to the user The method employs a urgent field which is carried in all segments transmitted The URG control flag indicates that the urgent field is meaningful and must be added to the segment sequence number to yield the urgent pointer The absence of this flag indicates that there is no urgent data outstanding To send an urgent indication the user must also send at least one data octet If the sending user also indicates a push timely delivery of the urgent information to the destination process is enhanced Managing the Window The window sent in each segment indicates the range of sequence numbers the sender of the window the data receiver is currently prepared to accept There is an assumption that this is related to the currently available data buffer space available for this connection Indicating a large window encourages transmissions If more data arrives than can be accepted it will be discarded This will result in excessive retransmissions adding unnecessarily to the load on the network and the TCPs Indicating a small window may restrict the transmission of data to the point of introducing a round trip delay between each new segment transmitted The mechanisms provided allow a TCP to advertise a large window and to subsequently advertise a much smaller window without having accepted that much data This so called shrinking the window is strongly discouraged The robustness principle dictates that TCPs will not shrink the window themselves but will be prepared for such behavior on the part of other TCPs The sending TCP must be prepared to accept from the user and send at least one octet of new data even if the send window is zero The sending TCP must regularly retransmit to the receiving TCP even when the window is zero Two minutes is recommended for the retransmission interval when the window is zero This retransmission is essential to guarantee that when either TCP has a zero window the re opening of the window will be reliably reported to the other When the receiving TCP has a zero window and a segment arrives it must still send an acknowledgment showing its next expected sequence number and current window zero The sending TCP packages the data to be transmitted into segments Page 42 September 1981 Transmission Control Protocol Functional Specification which fit the current window and may repackage segments on the retransmission queue Such repackaging is not required but may be helpful In a connection with a one way data flow the window information will be carried in acknowledgment segments that all have the same sequence number so there will be no way to reorder them if they arrive out of order This is not a serious problem but it will allow the window information to be on occasion temporarily based on old reports from the data receiver A refinement to avoid this problem is to act on the window information from segments that carry the highest acknowledgment number that is segments with acknowledgment number equal or greater than the highest previously received The window management procedure has significant influence on the communication performance The following comments are suggestions to implementers Window Management Suggestions Allocating a very small window causes data to be transmitted in many small segments when better performance is achieved using fewer large segments One suggestion for avoiding small windows is for the receiver to defer updating a window until the additional allocation is at least X percent of the maximum allocation possible for the connection where X might be 20 to 40 Another suggestion is for the sender to avoid sending small segments by waiting until the window is large enough before sending data If the the user signals a push function then the data must be sent even if it is a small segment Note that the acknowledgments should not be delayed or unnecessary retransmissions will result One strategy would be to send an acknowledgment when a small segment arrives with out updating the window information and then to send another acknowledgment with new window information when the window is larger The segment sent to probe a zero window may also begin a break up of transmitted data into smaller and smaller segments If a segment containing a single data octet sent to probe a zero window is accepted it consumes one octet of the window now available If the sending TCP simply sends as much as it can whenever the window is non zero the transmitted data will be broken into alternating big and small segments As time goes on occasional pauses in the receiver making window allocation available will Page 43 September 1981 Transmission Control Protocol Functional Specification result in breaking the big segments into a small and not quite so big pair And after a while the data transmission will be in mostly small segments The suggestion here is that the TCP implementations need to actively attempt to combine small window allocations into larger windows since the mechanisms for managing the window tend to lead to many small windows in the simplest minded implementations 3 8 Interfaces There are of course two interfaces of concern the user TCP interface and the TCP lower level interface We have a fairly elaborate model of the user TCP interface but the interface to the lower level protocol module is left unspecified here since it will be specified in detail by the specification of the lowel level protocol For the case that the lower level is IP we note some of the parameter values that TCPs might use User TCP Interface The following functional description of user commands to the TCP is at best fictional since every operating system will have different facilities Consequently we must warn readers that different TCP implementations may have different user interfaces However all TCPs must provide a certain minimum set of services to guarantee that all TCP implementations can support the same protocol hierarchy This section specifies the functional interfaces required of all TCP implementations TCP User Commands The following sections functionally characterize a USER TCP interface The notation used is similar to most procedure or function calls in high level languages but this usage is not meant to rule out trap type service calls e g SVCs UUOs EMTs The user commands described below specify the basic functions the TCP must perform to support interprocess communication Individual implementations must define their own exact format and may provide combinations or subsets of the basic functions in single calls In particular some implementations may wish to automatically OPEN a connection on the first SEND or RECEIVE issued by the user for a given connection Page 44 September 1981 Transmission Control Protocol Functional Specification In providing interprocess communication facilities the TCP must not only accept commands but must also return information to the processes it serves The latter consists of a general information about a connection e g interrupts remote close binding of unspecified foreign socket b replies to specific user commands indicating success or various types of failure Open Format OPEN local port foreign socket active passive timeout precedence security compartment options

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0793.txt (2016-02-14)
    Open archived version from archive


  • 5 6 7 8 9 0 1 Type Code Checksum Pointer unused Internet Header 64 bits of Original Data Datagram IP Fields Destination Address The source network and address from the original datagram s data ICMP Fields Type 12 Code 0 pointer indicates the error Checksum The checksum is the 16 bit ones s complement of the one s complement sum of the ICMP message starting with the ICMP Type For computing the checksum the checksum field should be zero This checksum may be replaced in the future Pointer If code 0 identifies the octet where an error was detected Internet Header 64 bits of Data Datagram The internet header plus the first 64 bits of the original datagram s data This data is used by the host to match the message to the appropriate process If a higher level protocol uses port numbers they are assumed to be in the first 64 data bits of the original datagram s data Page 8 September 1981 RFC 792 Description If the gateway or host processing a datagram finds a problem with the header parameters such that it cannot complete processing the datagram it must discard the datagram One potential source of such a problem is with incorrect arguments in an option The gateway or host may also notify the source host via the parameter problem message This message is only sent if the error caused the datagram to be discarded The pointer identifies the octet of the original datagram s header where the error was detected it may be in the middle of an option For example 1 indicates something is wrong with the Type of Service and if there are options present 20 indicates something is wrong with the type code of the first option Code 0 may be received from a gateway or a host Page 9 September 1981 RFC 792 Source Quench Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type Code Checksum unused Internet Header 64 bits of Original Data Datagram IP Fields Destination Address The source network and address of the original datagram s data ICMP Fields Type 4 Code 0 Checksum The checksum is the 16 bit ones s complement of the one s complement sum of the ICMP message starting with the ICMP Type For computing the checksum the checksum field should be zero This checksum may be replaced in the future Internet Header 64 bits of Data Datagram The internet header plus the first 64 bits of the original datagram s data This data is used by the host to match the message to the appropriate process If a higher level protocol uses port numbers they are assumed to be in the first 64 data bits of the original datagram s data Description A gateway may discard internet datagrams if it does not have the buffer space needed to queue the datagrams for output to the next network on the route to the destination network If a gateway Page 10 September 1981 RFC 792 discards a datagram it may send a source quench message to the internet source host of the datagram A destination host may also send a source quench message if datagrams arrive too fast to be processed The source quench message is a request to the host to cut back the rate at which it is sending traffic to the internet destination The gateway may send a source quench message for every message that it discards On receipt of a source quench message the source host should cut back the rate at which it is sending traffic to the specified destination until it no longer receives source quench messages from the gateway The source host can then gradually increase the rate at which it sends traffic to the destination until it again receives source quench messages The gateway or host may send the source quench message when it approaches its capacity limit rather than waiting until the capacity is exceeded This means that the data datagram which triggered the source quench message may be delivered Code 0 may be received from a gateway or a host Page 11 September 1981 RFC 792 Redirect Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Type Code Checksum Gateway Internet Address Internet Header 64 bits of Original Data Datagram IP Fields Destination Address The source network and address of the original datagram s data ICMP Fields Type 5 Code 0 Redirect datagrams for the Network 1 Redirect datagrams for the Host 2 Redirect datagrams for the Type of Service and Network 3 Redirect datagrams for the Type of Service and Host Checksum The checksum is the 16 bit ones s complement of the one s complement sum of the ICMP message starting with the ICMP Type For computing the checksum the checksum field should be zero This checksum may be replaced in the future Gateway Internet Address Address of the gateway to which traffic for the network specified in the internet destination network field of the original datagram s data should be sent Page 12 September 1981 RFC 792 Internet Header 64 bits of Data Datagram The internet header plus the first 64 bits of the original datagram s data This data is used by the host to match the message to the appropriate process If a higher level protocol uses port numbers they are assumed to be in the first 64 data bits of the original datagram s data Description The gateway sends a redirect message to a host in the following situation A gateway G1 receives an internet datagram from a host on a network to which the gateway is attached The gateway G1

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc0792.txt (2016-02-14)
    Open archived version from archive



  •