idnits 2.17.1 draft-ietf-tcpm-rfc793bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC6093, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC6691, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC879, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC6528, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1122, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1122, updated by this document, for RFC5378 checks: 1989-10-01) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 21, 2016) is 2957 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1981 (ref. '2') (Obsoleted by RFC 8201) ** Downref: Normative reference to an Informational RFC: RFC 2923 (ref. '5') -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '6') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 896 (ref. '7') (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 6093 (ref. '13') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6528 (ref. '14') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6691 (ref. '15') (Obsoleted by RFC 9293) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Eddy, Ed. 3 Internet-Draft MTI Systems 4 Obsoletes: 793, 879, 6093, 6528, 6691 March 21, 2016 5 (if approved) 6 Updates: 1122 (if approved) 7 Intended status: Standards Track 8 Expires: September 22, 2016 10 Transmission Control Protocol Specification 11 draft-ietf-tcpm-rfc793bis-02 13 Abstract 15 This document specifies the Internet's Transmission Control Protocol 16 (TCP). TCP is an important transport layer protocol in the Internet 17 stack, and has continuously evolved over decades of use and growth of 18 the Internet. Over this time, a number of changes have been made to 19 TCP as it was specified in RFC 793, though these have only been 20 documented in a piecemeal fashion. This document collects and brings 21 those changes together with the protocol specification from RFC 793. 22 This document obsoletes RFC 793 and several other RFCs (TODO: list 23 all actual RFCs when finished). 25 RFC EDITOR NOTE: If approved for publication as an RFC, this should 26 be marked additionally as "STD: 7" and replace RFC 793 in that role. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [3]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 22, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 81 3. Functional Specification . . . . . . . . . . . . . . . . . . 4 82 3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 4 83 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 14 85 3.4. Establishing a connection . . . . . . . . . . . . . . . . 20 86 3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 27 87 3.5.1. Half-Closed Connections . . . . . . . . . . . . . . . 30 88 3.6. Precedence and Security . . . . . . . . . . . . . . . . . 30 89 3.7. Segmentation . . . . . . . . . . . . . . . . . . . . . . 31 90 3.7.1. Maximum Segment Size Option . . . . . . . . . . . . . 32 91 3.7.2. Path MTU Discovery . . . . . . . . . . . . . . . . . 33 92 3.7.3. Interfaces with Variable MTU Values . . . . . . . . . 34 93 3.7.4. Nagle Algorithm . . . . . . . . . . . . . . . . . . . 34 94 3.7.5. IPv6 Jumbograms . . . . . . . . . . . . . . . . . . . 35 95 3.8. Data Communication . . . . . . . . . . . . . . . . . . . 35 96 3.9. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 39 97 3.9.1. User/TCP Interface . . . . . . . . . . . . . . . . . 39 98 3.9.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 47 99 3.10. Event Processing . . . . . . . . . . . . . . . . . . . . 47 100 3.11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 71 101 4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 76 102 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 103 6. Security and Privacy Considerations . . . . . . . . . . . . . 80 104 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 80 105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 106 8.1. Normative References . . . . . . . . . . . . . . . . . . 81 107 8.2. Informative References . . . . . . . . . . . . . . . . . 81 108 Appendix A. TCP Requirement Summary . . . . . . . . . . . . . . 82 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 86 111 1. Purpose and Scope 113 In 1981, RFC 793 [6] was released, documenting the Transmission 114 Control Protocol (TCP), and replacing earlier specifications for TCP 115 that had been published in the past. 117 Since then, TCP has been implemented many times, and has been used as 118 a transport protocol for numerous applications on the Internet. 120 For several decades, RFC 793 plus a number of other documents have 121 combined to serve as the specification for TCP [16]. Over time, a 122 number of errata have been identified on RFC 793, as well as 123 deficiencies in security, performance, and other aspects. A number 124 of enhancements has grown and been documented separately. These were 125 never accumulated together into an update to the base specification. 127 The purpose of this document is to bring together all of the IETF 128 Standards Track changes that have been made to the basic TCP 129 functional specification and unify them into an update of the RFC 793 130 protocol specification. Some companion documents are referenced for 131 important algorithms that TCP uses (e.g. for congestion control), but 132 have not been attempted to include in this document. This is a 133 conscious choice, as this base specification can be used with 134 multiple additional algorithms that are developed and incorporated 135 separately, but all TCP implementations need to implement this 136 specification as a common basis in order to interoperate. As some 137 additional TCP features have become quite complicated themselves 138 (e.g. advanced loss recovery and congestion control), future 139 companion documents may attempt to similarly bring these together. 141 In addition to the protocol specification that descibes the TCP 142 segment format, generation, and processing rules that are to be 143 implemented in code, RFC 793 and other updates also contain 144 informative and descriptive text for human readers to understand 145 aspects of the protocol design and operation. This document does not 146 attempt to alter or update this informative text, and is focused only 147 on updating the normative protocol specification. We preserve 148 references to the documentation containing the important explanations 149 and rationale, where appropriate. 151 This document is intended to be useful both in checking existing TCP 152 implementations for conformance, as well as in writing new 153 implementations. 155 2. Introduction 157 RFC 793 contains a discussion of the TCP design goals and provides 158 examples of its operation, including examples of connection 159 establishment, closing connections, and retransmitting packets to 160 repair losses. 162 This document describes the basic functionality expected in modern 163 implementations of TCP, and replaces the protocol specification in 164 RFC 793. It does not replicate or attempt to update the examples and 165 other discussion in RFC 793. Other documents are referenced to 166 provide explanation of the theory of operation, rationale, and 167 detailed discussion of design decisions. This document only focuses 168 on the normative behavior of the protocol. 170 TEMPORARY EDITOR'S NOTE: This is an early revision in the process of 171 updating RFC 793. Many planned changes are not yet incorporated. 173 ***Please do not use this revision as a basis for any work or 174 reference.*** 176 A list of changes from RFC 793 is contained in Section 4. 178 TEMPORARY EDITOR'S NOTE: the current revision of this document does 179 not yet collect all of the changes that will be in the final version. 180 The set of content changes planned for future revisions is kept in 181 Section 4. 183 3. Functional Specification 185 3.1. Header Format 187 TCP segments are sent as internet datagrams. The Internet Protocol 188 header carries several information fields, including the source and 189 destination host addresses [2]. A TCP header follows the internet 190 header, supplying information specific to the TCP protocol. This 191 division allows for the existence of host level protocols other than 192 TCP. 194 TCP Header Format 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Source Port | Destination Port | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Sequence Number | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Acknowledgment Number | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Data | |U|A|P|R|S|F| | 206 | Offset| Reserved |R|C|S|S|Y|I| Window | 207 | | |G|K|H|T|N|N| | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Checksum | Urgent Pointer | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Options | Padding | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | data | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 TCP Header Format 218 Note that one tick mark represents one bit position. 220 Figure 1 222 Source Port: 16 bits 224 The source port number. 226 Destination Port: 16 bits 228 The destination port number. 230 Sequence Number: 32 bits 232 The sequence number of the first data octet in this segment (except 233 when SYN is present). If SYN is present the sequence number is the 234 initial sequence number (ISN) and the first data octet is ISN+1. 236 Acknowledgment Number: 32 bits 237 If the ACK control bit is set this field contains the value of the 238 next sequence number the sender of the segment is expecting to 239 receive. Once a connection is established this is always sent. 241 Data Offset: 4 bits 243 The number of 32 bit words in the TCP Header. This indicates where 244 the data begins. The TCP header (even one including options) is an 245 integral number of 32 bits long. 247 Reserved: 4 bits 249 Reserved for future use. Must be zero. 251 Control Bits: 8 bits (from left to right): 253 CWR: Congestion Window Reduced 254 ECE: ECN-Echo 255 URG: Urgent Pointer field significant 256 ACK: Acknowledgment field significant 257 PSH: Push Function 258 RST: Reset the connection 259 SYN: Synchronize sequence numbers 260 FIN: No more data from sender 262 Window: 16 bits 264 The number of data octets beginning with the one indicated in the 265 acknowledgment field which the sender of this segment is willing to 266 accept. 268 The window size MUST be treated as an unsigned number, or else 269 large window sizes will appear like negative windows and TCP will 270 now work. It is RECOMMENDED that implementations will reserve 271 32-bit fields for the send and receive window sizes in the 272 connection record and do all window computations with 32 bits. 274 Checksum: 16 bits 276 The checksum field is the 16 bit one's complement of the one's 277 complement sum of all 16 bit words in the header and text. If a 278 segment contains an odd number of header and text octets to be 279 checksummed, the last octet is padded on the right with zeros to 280 form a 16 bit word for checksum purposes. The pad is not 281 transmitted as part of the segment. While computing the checksum, 282 the checksum field itself is replaced with zeros. 284 The checksum also covers a 96 bit pseudo header conceptually 285 prefixed to the TCP header. This pseudo header contains the Source 286 Address, the Destination Address, the Protocol, and TCP length. 287 This gives the TCP protection against misrouted segments. This 288 information is carried in the Internet Protocol and is transferred 289 across the TCP/Network interface in the arguments or results of 290 calls by the TCP on the IP. 292 +--------+--------+--------+--------+ 293 | Source Address | 294 +--------+--------+--------+--------+ 295 | Destination Address | 296 +--------+--------+--------+--------+ 297 | zero | PTCL | TCP Length | 298 +--------+--------+--------+--------+ 300 The TCP Length is the TCP header length plus the data length in 301 octets (this is not an explicitly transmitted quantity, but is 302 computed), and it does not count the 12 octets of the pseudo 303 header. 305 The TCP checksum is never optional. The sender MUST generate it 306 and the receiver MUST check it. 308 Urgent Pointer: 16 bits 310 This field communicates the current value of the urgent pointer as 311 a positive offset from the sequence number in this segment. The 312 urgent pointer points to the sequence number of the octet following 313 the urgent data. This field is only be interpreted in segments 314 with the URG control bit set. 316 Options: variable 318 Options may occupy space at the end of the TCP header and are a 319 multiple of 8 bits in length. All options are included in the 320 checksum. An option may begin on any octet boundary. There are 321 two cases for the format of an option: 323 Case 1: A single octet of option-kind. 325 Case 2: An octet of option-kind, an octet of option-length, and 326 the actual option-data octets. 328 The option-length counts the two octets of option-kind and option- 329 length as well as the option-data octets. 331 Note that the list of options may be shorter than the data offset 332 field might imply. The content of the header beyond the End-of- 333 Option option must be header padding (i.e., zero). 335 Currently defined options include (kind indicated in octal): 337 Kind Length Meaning 338 ---- ------ ------- 339 0 - End of option list. 340 1 - No-Operation. 341 2 4 Maximum Segment Size. 343 A TCP MUST be able to receive a TCP option in any segment. 344 A TCP MUST ignore without error any TCP option it does not 345 implement, assuming that the option has a length field (all TCP 346 options except End of option list and No-Operation have length 347 fields). TCP MUST be prepared to handle an illegal option length 348 (e.g., zero) without crashing; a suggested procedure is to reset 349 the connection and log the reason. 351 Specific Option Definitions 353 End of Option List 355 +--------+ 356 |00000000| 357 +--------+ 358 Kind=0 360 This option code indicates the end of the option list. This 361 might not coincide with the end of the TCP header according to 362 the Data Offset field. This is used at the end of all options, 363 not the end of each option, and need only be used if the end of 364 the options would not otherwise coincide with the end of the TCP 365 header. 367 No-Operation 369 +--------+ 370 |00000001| 371 +--------+ 372 Kind=1 374 This option code may be used between options, for example, to 375 align the beginning of a subsequent option on a word boundary. 376 There is no guarantee that senders will use this option, so 377 receivers must be prepared to process options even if they do 378 not begin on a word boundary. 380 Maximum Segment Size (MSS) 382 +--------+--------+---------+--------+ 383 |00000010|00000100| max seg size | 384 +--------+--------+---------+--------+ 385 Kind=2 Length=4 387 Maximum Segment Size Option Data: 16 bits 389 If this option is present, then it communicates the maximum 390 receive segment size at the TCP which sends this segment. This 391 field may be sent in the initial connection request (i.e., in 392 segments with the SYN control bit set) and must not be sent in 393 other segments. If this option is not used, any segment size is 394 allowed. A more complete description of this option is in 395 Section 3.7.1. 397 Padding: variable 399 The TCP header padding is used to ensure that the TCP header ends 400 and data begins on a 32 bit boundary. The padding is composed of 401 zeros. 403 3.2. Terminology 405 Before we can discuss very much about the operation of the TCP we 406 need to introduce some detailed terminology. The maintenance of a 407 TCP connection requires the remembering of several variables. We 408 conceive of these variables being stored in a connection record 409 called a Transmission Control Block or TCB. Among the variables 410 stored in the TCB are the local and remote socket numbers, the 411 security and precedence of the connection, pointers to the user's 412 send and receive buffers, pointers to the retransmit queue and to the 413 current segment. In addition several variables relating to the send 414 and receive sequence numbers are stored in the TCB. 416 Send Sequence Variables 418 SND.UNA - send unacknowledged 419 SND.NXT - send next 420 SND.WND - send window 421 SND.UP - send urgent pointer 422 SND.WL1 - segment sequence number used for last window update 423 SND.WL2 - segment acknowledgment number used for last window 424 update 425 ISS - initial send sequence number 427 Receive Sequence Variables 429 RCV.NXT - receive next 430 RCV.WND - receive window 431 RCV.UP - receive urgent pointer 432 IRS - initial receive sequence number 434 The following diagrams may help to relate some of these variables to 435 the sequence space. 437 Send Sequence Space 439 1 2 3 4 440 ----------|----------|----------|---------- 441 SND.UNA SND.NXT SND.UNA 442 +SND.WND 444 1 - old sequence numbers which have been acknowledged 445 2 - sequence numbers of unacknowledged data 446 3 - sequence numbers allowed for new data transmission 447 4 - future sequence numbers which are not yet allowed 449 Send Sequence Space 451 Figure 2 453 The send window is the portion of the sequence space labeled 3 in 454 Figure 2. 456 Receive Sequence Space 458 1 2 3 459 ----------|----------|---------- 460 RCV.NXT RCV.NXT 461 +RCV.WND 463 1 - old sequence numbers which have been acknowledged 464 2 - sequence numbers allowed for new reception 465 3 - future sequence numbers which are not yet allowed 467 Receive Sequence Space 469 Figure 3 471 The receive window is the portion of the sequence space labeled 2 in 472 Figure 3. 474 There are also some variables used frequently in the discussion that 475 take their values from the fields of the current segment. 477 Current Segment Variables 479 SEG.SEQ - segment sequence number 480 SEG.ACK - segment acknowledgment number 481 SEG.LEN - segment length 482 SEG.WND - segment window 483 SEG.UP - segment urgent pointer 484 SEG.PRC - segment precedence value 486 A connection progresses through a series of states during its 487 lifetime. The states are: LISTEN, SYN-SENT, SYN-RECEIVED, 488 ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, 489 TIME-WAIT, and the fictional state CLOSED. CLOSED is fictional 490 because it represents the state when there is no TCB, and therefore, 491 no connection. Briefly the meanings of the states are: 493 LISTEN - represents waiting for a connection request from any 494 remote TCP and port. 496 SYN-SENT - represents waiting for a matching connection request 497 after having sent a connection request. 499 SYN-RECEIVED - represents waiting for a confirming connection 500 request acknowledgment after having both received and sent a 501 connection request. 503 ESTABLISHED - represents an open connection, data received can be 504 delivered to the user. The normal state for the data transfer 505 phase of the connection. 507 FIN-WAIT-1 - represents waiting for a connection termination 508 request from the remote TCP, or an acknowledgment of the 509 connection termination request previously sent. 511 FIN-WAIT-2 - represents waiting for a connection termination 512 request from the remote TCP. 514 CLOSE-WAIT - represents waiting for a connection termination 515 request from the local user. 517 CLOSING - represents waiting for a connection termination request 518 acknowledgment from the remote TCP. 520 LAST-ACK - represents waiting for an acknowledgment of the 521 connection termination request previously sent to the remote TCP 522 (this termination request sent to the remote TCP already included 523 an acknowledgment of the termination request sent from the remote 524 TCP). 526 TIME-WAIT - represents waiting for enough time to pass to be sure 527 the remote TCP received the acknowledgment of its connection 528 termination request. 530 CLOSED - represents no connection state at all. 532 A TCP connection progresses from one state to another in response to 533 events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE, 534 ABORT, and STATUS; the incoming segments, particularly those 535 containing the SYN, ACK, RST and FIN flags; and timeouts. 537 The state diagram in Figure 4 illustrates only state changes, 538 together with the causing events and resulting actions, but addresses 539 neither error conditions nor actions which are not connected with 540 state changes. In a later section, more detail is offered with 541 respect to the reaction of the TCP to events. 543 NOTA BENE: this diagram is only a summary and must not be taken as 544 the total specification. 546 +---------+ ---------\ active OPEN 547 | CLOSED | \ ----------- 548 +---------+<---------\ \ create TCB 549 | ^ \ \ snd SYN 550 passive OPEN | | CLOSE \ \ 551 ------------ | | ---------- \ \ 552 create TCB | | delete TCB \ \ 553 V | \ \ 554 rcv RST (note 1) +---------+ CLOSE | \ 555 -------------------->| LISTEN | ---------- | | 556 / +---------+ delete TCB | | 557 / rcv SYN | | SEND | | 558 / ----------- | | ------- | V 559 +--------+ snd SYN,ACK / \ snd SYN +--------+ 560 | |<----------------- ------------------>| | 561 | SYN | rcv SYN | SYN | 562 | RCVD |<-----------------------------------------------| SENT | 563 | | snd SYN,ACK | | 564 | |------------------ -------------------| | 565 +--------+ rcv ACK of SYN \ / rcv SYN,ACK +--------+ 566 | -------------- | | ----------- 567 | x | | snd ACK 568 | V V 569 | CLOSE +---------+ 570 | ------- | ESTAB | 571 | snd FIN +---------+ 572 | CLOSE | | rcv FIN 573 V ------- | | ------- 574 +---------+ snd FIN / \ snd ACK +---------+ 575 | FIN |<----------------- ------------------>| CLOSE | 576 | WAIT-1 |------------------ | WAIT | 577 +---------+ rcv FIN \ +---------+ 578 | rcv ACK of FIN ------- | CLOSE | 579 | -------------- snd ACK | ------- | 580 V x V snd FIN V 581 +---------+ +---------+ +---------+ 582 |FINWAIT-2| | CLOSING | | LAST-ACK| 583 +---------+ +---------+ +---------+ 584 | rcv ACK of FIN | rcv ACK of FIN | 585 | rcv FIN -------------- | Timeout=2MSL -------------- | 586 | ------- x V ------------ x V 587 \ snd ACK +---------+delete TCB +---------+ 588 ------------------------>|TIME WAIT|------------------>| CLOSED | 589 +---------+ +---------+ 591 note 1: The transition from SYN-RCVD to LISTEN on receiving a RST is 592 conditional on having reached SYN-RCVD after a passive open. 594 note 2: An unshown transition exists from FIN-WAIT-1 to TIME-WAIT if 595 a FIN is received and the local FIN is also acknowledged. 597 TCP Connection State Diagram 598 Figure 4 600 3.3. Sequence Numbers 602 A fundamental notion in the design is that every octet of data sent 603 over a TCP connection has a sequence number. Since every octet is 604 sequenced, each of them can be acknowledged. The acknowledgment 605 mechanism employed is cumulative so that an acknowledgment of 606 sequence number X indicates that all octets up to but not including X 607 have been received. This mechanism allows for straight-forward 608 duplicate detection in the presence of retransmission. Numbering of 609 octets within a segment is that the first data octet immediately 610 following the header is the lowest numbered, and the following octets 611 are numbered consecutively. 613 It is essential to remember that the actual sequence number space is 614 finite, though very large. This space ranges from 0 to 2**32 - 1. 615 Since the space is finite, all arithmetic dealing with sequence 616 numbers must be performed modulo 2**32. This unsigned arithmetic 617 preserves the relationship of sequence numbers as they cycle from 618 2**32 - 1 to 0 again. There are some subtleties to computer modulo 619 arithmetic, so great care should be taken in programming the 620 comparison of such values. The symbol "=<" means "less than or 621 equal" (modulo 2**32). 623 The typical kinds of sequence number comparisons which the TCP must 624 perform include: 626 (a) Determining that an acknowledgment refers to some sequence 627 number sent but not yet acknowledged. 629 (b) Determining that all sequence numbers occupied by a segment 630 have been acknowledged (e.g., to remove the segment from a 631 retransmission queue). 633 (c) Determining that an incoming segment contains sequence numbers 634 which are expected (i.e., that the segment "overlaps" the receive 635 window). 637 In response to sending data the TCP will receive acknowledgments. 638 The following comparisons are needed to process the acknowledgments. 640 SND.UNA = oldest unacknowledged sequence number 642 SND.NXT = next sequence number to be sent 644 SEG.ACK = acknowledgment from the receiving TCP (next sequence 645 number expected by the receiving TCP) 646 SEG.SEQ = first sequence number of a segment 648 SEG.LEN = the number of octets occupied by the data in the segment 649 (counting SYN and FIN) 651 SEG.SEQ+SEG.LEN-1 = last sequence number of a segment 653 A new acknowledgment (called an "acceptable ack"), is one for which 654 the inequality below holds: 656 SND.UNA < SEG.ACK =< SND.NXT 658 A segment on the retransmission queue is fully acknowledged if the 659 sum of its sequence number and length is less or equal than the 660 acknowledgment value in the incoming segment. 662 When data is received the following comparisons are needed: 664 RCV.NXT = next sequence number expected on an incoming segments, 665 and is the left or lower edge of the receive window 667 RCV.NXT+RCV.WND-1 = last sequence number expected on an incoming 668 segment, and is the right or upper edge of the receive window 670 SEG.SEQ = first sequence number occupied by the incoming segment 672 SEG.SEQ+SEG.LEN-1 = last sequence number occupied by the incoming 673 segment 675 A segment is judged to occupy a portion of valid receive sequence 676 space if 678 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 680 or 682 RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 684 The first part of this test checks to see if the beginning of the 685 segment falls in the window, the second part of the test checks to 686 see if the end of the segment falls in the window; if the segment 687 passes either part of the test it contains data in the window. 689 Actually, it is a little more complicated than this. Due to zero 690 windows and zero length segments, we have four cases for the 691 acceptability of an incoming segment: 693 Segment Receive Test 694 Length Window 695 ------- ------- ------------------------------------------- 697 0 0 SEG.SEQ = RCV.NXT 699 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 701 >0 0 not acceptable 703 >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 704 or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 706 Note that when the receive window is zero no segments should be 707 acceptable except ACK segments. Thus, it is be possible for a TCP to 708 maintain a zero receive window while transmitting data and receiving 709 ACKs. However, even when the receive window is zero, a TCP must 710 process the RST and URG fields of all incoming segments. 712 We have taken advantage of the numbering scheme to protect certain 713 control information as well. This is achieved by implicitly 714 including some control flags in the sequence space so they can be 715 retransmitted and acknowledged without confusion (i.e., one and only 716 one copy of the control will be acted upon). Control information is 717 not physically carried in the segment data space. Consequently, we 718 must adopt rules for implicitly assigning sequence numbers to 719 control. The SYN and FIN are the only controls requiring this 720 protection, and these controls are used only at connection opening 721 and closing. For sequence number purposes, the SYN is considered to 722 occur before the first actual data octet of the segment in which it 723 occurs, while the FIN is considered to occur after the last actual 724 data octet in a segment in which it occurs. The segment length 725 (SEG.LEN) includes both data and sequence space occupying controls. 726 When a SYN is present then SEG.SEQ is the sequence number of the SYN. 728 Initial Sequence Number Selection 730 The protocol places no restriction on a particular connection being 731 used over and over again. A connection is defined by a pair of 732 sockets. New instances of a connection will be referred to as 733 incarnations of the connection. The problem that arises from this is 734 -- "how does the TCP identify duplicate segments from previous 735 incarnations of the connection?" This problem becomes apparent if 736 the connection is being opened and closed in quick succession, or if 737 the connection breaks with loss of memory and is then reestablished. 739 To avoid confusion we must prevent segments from one incarnation of a 740 connection from being used while the same sequence numbers may still 741 be present in the network from an earlier incarnation. We want to 742 assure this, even if a TCP crashes and loses all knowledge of the 743 sequence numbers it has been using. When new connections are 744 created, an initial sequence number (ISN) generator is employed which 745 selects a new 32 bit ISN. There are security issues that result if 746 an off-path attacker is able to predict or guess ISN values. 748 The recommended ISN generator is based on the combination of a 749 (possibly fictitious) 32 bit clock whose low order bit is incremented 750 roughly every 4 microseconds, and a pseudorandom hash function (PRF). 751 The clock component is intended to insure that with a Maximum Segment 752 Lifetime (MSL), generated ISNs will be unique, since it cycles 753 approximately every 4.55 hours, which is much longer than the MSL. 754 This recommended algorithm is further described in RFC 1948 and 755 builds on the basic clock-driven algorithm from RFC 793. 757 A TCP MUST use a clock-driven selection of initial sequence numbers, 758 and SHOULD generate its Initial Sequence Numbers with the expression: 760 ISN = M + F(localip, localport, remoteip, remoteport, secretkey) 762 where M is the 4 microsecond timer, and F() is a pseudorandom 763 function (PRF) of the connection's identifying parameters ("localip, 764 localport, remoteip, remoteport") and a secret key ("secretkey"). 765 F() MUST NOT be computable from the outside, or an attacker could 766 still guess at sequence numbers from the ISN used for some other 767 connection. The PRF could be implemented as a cryptographic has of 768 the concatenation of the TCP connection parameters and some secret 769 data. For discussion of the selection of a specific hash algorithm 770 and management of the secret key data, please see Section 3 of [14]. 772 For each connection there is a send sequence number and a receive 773 sequence number. The initial send sequence number (ISS) is chosen by 774 the data sending TCP, and the initial receive sequence number (IRS) 775 is learned during the connection establishing procedure. 777 For a connection to be established or initialized, the two TCPs must 778 synchronize on each other's initial sequence numbers. This is done 779 in an exchange of connection establishing segments carrying a control 780 bit called "SYN" (for synchronize) and the initial sequence numbers. 781 As a shorthand, segments carrying the SYN bit are also called "SYNs". 782 Hence, the solution requires a suitable mechanism for picking an 783 initial sequence number and a slightly involved handshake to exchange 784 the ISN's. 786 The synchronization requires each side to send it's own initial 787 sequence number and to receive a confirmation of it in acknowledgment 788 from the other side. Each side must also receive the other side's 789 initial sequence number and send a confirming acknowledgment. 791 1) A --> B SYN my sequence number is X 792 2) A <-- B ACK your sequence number is X 793 3) A <-- B SYN my sequence number is Y 794 4) A --> B ACK your sequence number is Y 796 Because steps 2 and 3 can be combined in a single message this is 797 called the three way (or three message) handshake. 799 A three way handshake is necessary because sequence numbers are not 800 tied to a global clock in the network, and TCPs may have different 801 mechanisms for picking the ISN's. The receiver of the first SYN has 802 no way of knowing whether the segment was an old delayed one or not, 803 unless it remembers the last sequence number used on the connection 804 (which is not always possible), and so it must ask the sender to 805 verify this SYN. The three way handshake and the advantages of a 806 clock-driven scheme are discussed in [3]. 808 Knowing When to Keep Quiet 810 To be sure that a TCP does not create a segment that carries a 811 sequence number which may be duplicated by an old segment remaining 812 in the network, the TCP must keep quiet for an MSL before assigning 813 any sequence numbers upon starting up or recovering from a crash in 814 which memory of sequence numbers in use was lost. For this 815 specification the MSL is taken to be 2 minutes. This is an 816 engineering choice, and may be changed if experience indicates it is 817 desirable to do so. Note that if a TCP is reinitialized in some 818 sense, yet retains its memory of sequence numbers in use, then it 819 need not wait at all; it must only be sure to use sequence numbers 820 larger than those recently used. 822 The TCP Quiet Time Concept 824 This specification provides that hosts which "crash" without 825 retaining any knowledge of the last sequence numbers transmitted on 826 each active (i.e., not closed) connection shall delay emitting any 827 TCP segments for at least the agreed MSL in the internet system of 828 which the host is a part. In the paragraphs below, an explanation 829 for this specification is given. TCP implementors may violate the 830 "quiet time" restriction, but only at the risk of causing some old 831 data to be accepted as new or new data rejected as old duplicated by 832 some receivers in the internet system. 834 TCPs consume sequence number space each time a segment is formed and 835 entered into the network output queue at a source host. The 836 duplicate detection and sequencing algorithm in the TCP protocol 837 relies on the unique binding of segment data to sequence space to the 838 extent that sequence numbers will not cycle through all 2**32 values 839 before the segment data bound to those sequence numbers has been 840 delivered and acknowledged by the receiver and all duplicate copies 841 of the segments have "drained" from the internet. Without such an 842 assumption, two distinct TCP segments could conceivably be assigned 843 the same or overlapping sequence numbers, causing confusion at the 844 receiver as to which data is new and which is old. Remember that 845 each segment is bound to as many consecutive sequence numbers as 846 there are octets of data and SYN or FIN flags in the segment. 848 Under normal conditions, TCPs keep track of the next sequence number 849 to emit and the oldest awaiting acknowledgment so as to avoid 850 mistakenly using a sequence number over before its first use has been 851 acknowledged. This alone does not guarantee that old duplicate data 852 is drained from the net, so the sequence space has been made very 853 large to reduce the probability that a wandering duplicate will cause 854 trouble upon arrival. At 2 megabits/sec. it takes 4.5 hours to use 855 up 2**32 octets of sequence space. Since the maximum segment 856 lifetime in the net is not likely to exceed a few tens of seconds, 857 this is deemed ample protection for foreseeable nets, even if data 858 rates escalate to l0's of megabits/sec. At 100 megabits/sec, the 859 cycle time is 5.4 minutes which may be a little short, but still 860 within reason. 862 The basic duplicate detection and sequencing algorithm in TCP can be 863 defeated, however, if a source TCP does not have any memory of the 864 sequence numbers it last used on a given connection. For example, if 865 the TCP were to start all connections with sequence number 0, then 866 upon crashing and restarting, a TCP might re-form an earlier 867 connection (possibly after half-open connection resolution) and emit 868 packets with sequence numbers identical to or overlapping with 869 packets still in the network which were emitted on an earlier 870 incarnation of the same connection. In the absence of knowledge 871 about the sequence numbers used on a particular connection, the TCP 872 specification recommends that the source delay for MSL seconds before 873 emitting segments on the connection, to allow time for segments from 874 the earlier connection incarnation to drain from the system. 876 Even hosts which can remember the time of day and used it to select 877 initial sequence number values are not immune from this problem 878 (i.e., even if time of day is used to select an initial sequence 879 number for each new connection incarnation). 881 Suppose, for example, that a connection is opened starting with 882 sequence number S. Suppose that this connection is not used much and 883 that eventually the initial sequence number function (ISN(t)) takes 884 on a value equal to the sequence number, say S1, of the last segment 885 sent by this TCP on a particular connection. Now suppose, at this 886 instant, the host crashes, recovers, and establishes a new 887 incarnation of the connection. The initial sequence number chosen is 888 S1 = ISN(t) -- last used sequence number on old incarnation of 889 connection! If the recovery occurs quickly enough, any old 890 duplicates in the net bearing sequence numbers in the neighborhood of 891 S1 may arrive and be treated as new packets by the receiver of the 892 new incarnation of the connection. 894 The problem is that the recovering host may not know for how long it 895 crashed nor does it know whether there are still old duplicates in 896 the system from earlier connection incarnations. 898 One way to deal with this problem is to deliberately delay emitting 899 segments for one MSL after recovery from a crash- this is the "quiet 900 time" specification. Hosts which prefer to avoid waiting are willing 901 to risk possible confusion of old and new packets at a given 902 destination may choose not to wait for the "quite time". 903 Implementors may provide TCP users with the ability to select on a 904 connection by connection basis whether to wait after a crash, or may 905 informally implement the "quite time" for all connections. 906 Obviously, even where a user selects to "wait," this is not necessary 907 after the host has been "up" for at least MSL seconds. 909 To summarize: every segment emitted occupies one or more sequence 910 numbers in the sequence space, the numbers occupied by a segment are 911 "busy" or "in use" until MSL seconds have passed, upon crashing a 912 block of space-time is occupied by the octets and SYN or FIN flags of 913 the last emitted segment, if a new connection is started too soon and 914 uses any of the sequence numbers in the space-time footprint of the 915 last segment of the previous connection incarnation, there is a 916 potential sequence number overlap area which could cause confusion at 917 the receiver. 919 3.4. Establishing a connection 921 The "three-way handshake" is the procedure used to establish a 922 connection. This procedure normally is initiated by one TCP and 923 responded to by another TCP. The procedure also works if two TCP 924 simultaneously initiate the procedure. When simultaneous attempt 925 occurs, each TCP receives a "SYN" segment which carries no 926 acknowledgment after it has sent a "SYN". Of course, the arrival of 927 an old duplicate "SYN" segment can potentially make it appear, to the 928 recipient, that a simultaneous connection initiation is in progress. 929 Proper use of "reset" segments can disambiguate these cases. 931 Several examples of connection initiation follow. Although these 932 examples do not show connection synchronization using data-carrying 933 segments, this is perfectly legitimate, so long as the receiving TCP 934 doesn't deliver the data to the user until it is clear the data is 935 valid (i.e., the data must be buffered at the receiver until the 936 connection reaches the ESTABLISHED state). The three-way handshake 937 reduces the possibility of false connections. It is the 938 implementation of a trade-off between memory and messages to provide 939 information for this checking. 941 The simplest three-way handshake is shown in Figure 5 below. The 942 figures should be interpreted in the following way. Each line is 943 numbered for reference purposes. Right arrows (-->) indicate 944 departure of a TCP segment from TCP A to TCP B, or arrival of a 945 segment at B from A. Left arrows (<--), indicate the reverse. 946 Ellipsis (...) indicates a segment which is still in the network 947 (delayed). An "XXX" indicates a segment which is lost or rejected. 948 Comments appear in parentheses. TCP states represent the state AFTER 949 the departure or arrival of the segment (whose contents are shown in 950 the center of each line). Segment contents are shown in abbreviated 951 form, with sequence number, control flags, and ACK field. Other 952 fields such as window, addresses, lengths, and text have been left 953 out in the interest of clarity. 955 TCP A TCP B 957 1. CLOSED LISTEN 959 2. SYN-SENT --> --> SYN-RECEIVED 961 3. ESTABLISHED <-- <-- SYN-RECEIVED 963 4. ESTABLISHED --> --> ESTABLISHED 965 5. ESTABLISHED --> --> ESTABLISHED 967 Basic 3-Way Handshake for Connection Synchronization 969 Figure 5 971 In line 2 of Figure 5, TCP A begins by sending a SYN segment 972 indicating that it will use sequence numbers starting with sequence 973 number 100. In line 3, TCP B sends a SYN and acknowledges the SYN it 974 received from TCP A. Note that the acknowledgment field indicates 975 TCP B is now expecting to hear sequence 101, acknowledging the SYN 976 which occupied sequence 100. 978 At line 4, TCP A responds with an empty segment containing an ACK for 979 TCP B's SYN; and in line 5, TCP A sends some data. Note that the 980 sequence number of the segment in line 5 is the same as in line 4 981 because the ACK does not occupy sequence number space (if it did, we 982 would wind up ACKing ACK's!). 984 Simultaneous initiation is only slightly more complex, as is shown in 985 Figure 6. Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to 986 ESTABLISHED. 988 TCP A TCP B 990 1. CLOSED CLOSED 992 2. SYN-SENT --> ... 994 3. SYN-RECEIVED <-- <-- SYN-SENT 996 4. ... --> SYN-RECEIVED 998 5. SYN-RECEIVED --> ... 1000 6. ESTABLISHED <-- <-- SYN-RECEIVED 1002 7. ... --> ESTABLISHED 1004 Simultaneous Connection Synchronization 1006 Figure 6 1008 A TCP MUST support simultaneous open attempts. 1010 Note that a TCP implementation MUST keep track of whether a 1011 connection has reached SYN_RCVD state as the result of a passive OPEN 1012 or an active OPEN. 1014 The principle reason for the three-way handshake is to prevent old 1015 duplicate connection initiations from causing confusion. To deal 1016 with this, a special control message, reset, has been devised. If 1017 the receiving TCP is in a non-synchronized state (i.e., SYN-SENT, 1018 SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset. 1019 If the TCP is in one of the synchronized states (ESTABLISHED, FIN- 1020 WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it 1021 aborts the connection and informs its user. We discuss this latter 1022 case under "half-open" connections below. 1024 TCP A TCP B 1026 1. CLOSED LISTEN 1028 2. SYN-SENT --> ... 1030 3. (duplicate) ... --> SYN-RECEIVED 1032 4. SYN-SENT <-- <-- SYN-RECEIVED 1034 5. SYN-SENT --> --> LISTEN 1036 6. ... --> SYN-RECEIVED 1038 7. SYN-SENT <-- <-- SYN-RECEIVED 1040 8. ESTABLISHED --> --> ESTABLISHED 1042 Recovery from Old Duplicate SYN 1044 Figure 7 1046 As a simple example of recovery from old duplicates, consider 1047 Figure 7. At line 3, an old duplicate SYN arrives at TCP B. TCP B 1048 cannot tell that this is an old duplicate, so it responds normally 1049 (line 4). TCP A detects that the ACK field is incorrect and returns 1050 a RST (reset) with its SEQ field selected to make the segment 1051 believable. TCP B, on receiving the RST, returns to the LISTEN 1052 state. When the original SYN (pun intended) finally arrives at line 1053 6, the synchronization proceeds normally. If the SYN at line 6 had 1054 arrived before the RST, a more complex exchange might have occurred 1055 with RST's sent in both directions. 1057 Half-Open Connections and Other Anomalies 1059 An established connection is said to be "half-open" if one of the 1060 TCPs has closed or aborted the connection at its end without the 1061 knowledge of the other, or if the two ends of the connection have 1062 become desynchronized owing to a crash that resulted in loss of 1063 memory. Such connections will automatically become reset if an 1064 attempt is made to send data in either direction. However, half-open 1065 connections are expected to be unusual, and the recovery procedure is 1066 mildly involved. 1068 If at site A the connection no longer exists, then an attempt by the 1069 user at site B to send any data on it will result in the site B TCP 1070 receiving a reset control message. Such a message indicates to the 1071 site B TCP that something is wrong, and it is expected to abort the 1072 connection. 1074 Assume that two user processes A and B are communicating with one 1075 another when a crash occurs causing loss of memory to A's TCP. 1076 Depending on the operating system supporting A's TCP, it is likely 1077 that some error recovery mechanism exists. When the TCP is up again, 1078 A is likely to start again from the beginning or from a recovery 1079 point. As a result, A will probably try to OPEN the connection again 1080 or try to SEND on the connection it believes open. In the latter 1081 case, it receives the error message "connection not open" from the 1082 local (A's) TCP. In an attempt to establish the connection, A's TCP 1083 will send a segment containing SYN. This scenario leads to the 1084 example shown in Figure 8. After TCP A crashes, the user attempts to 1085 re-open the connection. TCP B, in the meantime, thinks the 1086 connection is open. 1088 TCP A TCP B 1090 1. (CRASH) (send 300,receive 100) 1092 2. CLOSED ESTABLISHED 1094 3. SYN-SENT --> --> (??) 1096 4. (!!) <-- <-- ESTABLISHED 1098 5. SYN-SENT --> --> (Abort!!) 1100 6. SYN-SENT CLOSED 1102 7. SYN-SENT --> --> 1104 Half-Open Connection Discovery 1106 Figure 8 1108 When the SYN arrives at line 3, TCP B, being in a synchronized state, 1109 and the incoming segment outside the window, responds with an 1110 acknowledgment indicating what sequence it next expects to hear (ACK 1111 100). TCP A sees that this segment does not acknowledge anything it 1112 sent and, being unsynchronized, sends a reset (RST) because it has 1113 detected a half-open connection. TCP B aborts at line 5. TCP A will 1114 continue to try to establish the connection; the problem is now 1115 reduced to the basic 3-way handshake of Figure 5. 1117 An interesting alternative case occurs when TCP A crashes and TCP B 1118 tries to send data on what it thinks is a synchronized connection. 1120 This is illustrated in Figure 9. In this case, the data arriving at 1121 TCP A from TCP B (line 2) is unacceptable because no such connection 1122 exists, so TCP A sends a RST. The RST is acceptable so TCP B 1123 processes it and aborts the connection. 1125 TCP A TCP B 1127 1. (CRASH) (send 300,receive 100) 1129 2. (??) <-- <-- ESTABLISHED 1131 3. --> --> (ABORT!!) 1133 Active Side Causes Half-Open Connection Discovery 1135 Figure 9 1137 In Figure 10, we find the two TCPs A and B with passive connections 1138 waiting for SYN. An old duplicate arriving at TCP B (line 2) stirs B 1139 into action. A SYN-ACK is returned (line 3) and causes TCP A to 1140 generate a RST (the ACK in line 3 is not acceptable). TCP B accepts 1141 the reset and returns to its passive LISTEN state. 1143 TCP A TCP B 1145 1. LISTEN LISTEN 1147 2. ... --> SYN-RECEIVED 1149 3. (??) <-- <-- SYN-RECEIVED 1151 4. --> --> (return to LISTEN!) 1153 5. LISTEN LISTEN 1155 Old Duplicate SYN Initiates a Reset on two Passive Sockets 1157 Figure 10 1159 A variety of other cases are possible, all of which are accounted for 1160 by the following rules for RST generation and processing. 1162 Reset Generation 1163 As a general rule, reset (RST) must be sent whenever a segment 1164 arrives which apparently is not intended for the current connection. 1165 A reset must not be sent if it is not clear that this is the case. 1167 There are three groups of states: 1169 1. If the connection does not exist (CLOSED) then a reset is sent 1170 in response to any incoming segment except another reset. In 1171 particular, SYNs addressed to a non-existent connection are 1172 rejected by this means. 1174 If the incoming segment has the ACK bit set, the reset takes its 1175 sequence number from the ACK field of the segment, otherwise the 1176 reset has sequence number zero and the ACK field is set to the sum 1177 of the sequence number and segment length of the incoming segment. 1178 The connection remains in the CLOSED state. 1180 2. If the connection is in any non-synchronized state (LISTEN, 1181 SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges 1182 something not yet sent (the segment carries an unacceptable ACK), 1183 or if an incoming segment has a security level or compartment 1184 which does not exactly match the level and compartment requested 1185 for the connection, a reset is sent. 1187 If our SYN has not been acknowledged and the precedence level of 1188 the incoming segment is higher than the precedence level requested 1189 then either raise the local precedence level (if allowed by the 1190 user and the system) or send a reset; or if the precedence level 1191 of the incoming segment is lower than the precedence level 1192 requested then continue as if the precedence matched exactly (if 1193 the remote TCP cannot raise the precedence level to match ours 1194 this will be detected in the next segment it sends, and the 1195 connection will be terminated then). If our SYN has been 1196 acknowledged (perhaps in this incoming segment) the precedence 1197 level of the incoming segment must match the local precedence 1198 level exactly, if it does not a reset must be sent. 1200 If the incoming segment has an ACK field, the reset takes its 1201 sequence number from the ACK field of the segment, otherwise the 1202 reset has sequence number zero and the ACK field is set to the sum 1203 of the sequence number and segment length of the incoming segment. 1204 The connection remains in the same state. 1206 3. If the connection is in a synchronized state (ESTABLISHED, 1207 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), 1208 any unacceptable segment (out of window sequence number or 1209 unacceptable acknowledgment number) must elicit only an empty 1210 acknowledgment segment containing the current send-sequence number 1211 and an acknowledgment indicating the next sequence number expected 1212 to be received, and the connection remains in the same state. 1214 If an incoming segment has a security level, or compartment, or 1215 precedence which does not exactly match the level, and 1216 compartment, and precedence requested for the connection,a reset 1217 is sent and the connection goes to the CLOSED state. The reset 1218 takes its sequence number from the ACK field of the incoming 1219 segment. 1221 Reset Processing 1223 In all states except SYN-SENT, all reset (RST) segments are validated 1224 by checking their SEQ-fields. A reset is valid if its sequence 1225 number is in the window. In the SYN-SENT state (a RST received in 1226 response to an initial SYN), the RST is acceptable if the ACK field 1227 acknowledges the SYN. 1229 The receiver of a RST first validates it, then changes state. If the 1230 receiver was in the LISTEN state, it ignores it. If the receiver was 1231 in SYN-RECEIVED state and had previously been in the LISTEN state, 1232 then the receiver returns to the LISTEN state, otherwise the receiver 1233 aborts the connection and goes to the CLOSED state. If the receiver 1234 was in any other state, it aborts the connection and advises the user 1235 and goes to the CLOSED state. 1237 TCP SHOULD allow a received RST segment to include data. 1239 3.5. Closing a Connection 1241 CLOSE is an operation meaning "I have no more data to send." The 1242 notion of closing a full-duplex connection is subject to ambiguous 1243 interpretation, of course, since it may not be obvious how to treat 1244 the receiving side of the connection. We have chosen to treat CLOSE 1245 in a simplex fashion. The user who CLOSEs may continue to RECEIVE 1246 until he is told that the other side has CLOSED also. Thus, a 1247 program could initiate several SENDs followed by a CLOSE, and then 1248 continue to RECEIVE until signaled that a RECEIVE failed because the 1249 other side has CLOSED. We assume that the TCP will signal a user, 1250 even if no RECEIVEs are outstanding, that the other side has closed, 1251 so the user can terminate his side gracefully. A TCP will reliably 1252 deliver all buffers SENT before the connection was CLOSED so a user 1253 who expects no data in return need only wait to hear the connection 1254 was CLOSED successfully to know that all his data was received at the 1255 destination TCP. Users must keep reading connections they close for 1256 sending until the TCP says no more data. 1258 There are essentially three cases: 1260 1) The user initiates by telling the TCP to CLOSE the connection 1262 2) The remote TCP initiates by sending a FIN control signal 1264 3) Both users CLOSE simultaneously 1266 Case 1: Local user initiates the close 1268 In this case, a FIN segment can be constructed and placed on the 1269 outgoing segment queue. No further SENDs from the user will be 1270 accepted by the TCP, and it enters the FIN-WAIT-1 state. RECEIVEs 1271 are allowed in this state. All segments preceding and including 1272 FIN will be retransmitted until acknowledged. When the other TCP 1273 has both acknowledged the FIN and sent a FIN of its own, the first 1274 TCP can ACK this FIN. Note that a TCP receiving a FIN will ACK 1275 but not send its own FIN until its user has CLOSED the connection 1276 also. 1278 Case 2: TCP receives a FIN from the network 1280 If an unsolicited FIN arrives from the network, the receiving TCP 1281 can ACK it and tell the user that the connection is closing. The 1282 user will respond with a CLOSE, upon which the TCP can send a FIN 1283 to the other TCP after sending any remaining data. The TCP then 1284 waits until its own FIN is acknowledged whereupon it deletes the 1285 connection. If an ACK is not forthcoming, after the user timeout 1286 the connection is aborted and the user is told. 1288 Case 3: both users close simultaneously 1290 A simultaneous CLOSE by users at both ends of a connection causes 1291 FIN segments to be exchanged. When all segments preceding the 1292 FINs have been processed and acknowledged, each TCP can ACK the 1293 FIN it has received. Both will, upon receiving these ACKs, delete 1294 the connection. 1296 TCP A TCP B 1298 1. ESTABLISHED ESTABLISHED 1300 2. (Close) 1301 FIN-WAIT-1 --> --> CLOSE-WAIT 1303 3. FIN-WAIT-2 <-- <-- CLOSE-WAIT 1305 4. (Close) 1306 TIME-WAIT <-- <-- LAST-ACK 1308 5. TIME-WAIT --> --> CLOSED 1310 6. (2 MSL) 1311 CLOSED 1313 Normal Close Sequence 1315 Figure 11 1317 TCP A TCP B 1319 1. ESTABLISHED ESTABLISHED 1321 2. (Close) (Close) 1322 FIN-WAIT-1 --> ... FIN-WAIT-1 1323 <-- <-- 1324 ... --> 1326 3. CLOSING --> ... CLOSING 1327 <-- <-- 1328 ... --> 1330 4. TIME-WAIT TIME-WAIT 1331 (2 MSL) (2 MSL) 1332 CLOSED CLOSED 1334 Simultaneous Close Sequence 1336 Figure 12 1338 A TCP connection may terminate in two ways: (1) the normal TCP close 1339 sequence using a FIN handshake, and (2) an "abort" in which one or 1340 more RST segments are sent and the connection state is immediately 1341 discarded. If a TCP connection is closed by the remote site, the 1342 local application MUST be informed whether it closed normally or was 1343 aborted. 1345 3.5.1. Half-Closed Connections 1347 The normal TCP close sequence delivers buffered data reliably in both 1348 directions. Since the two directions of a TCP connection are closed 1349 independently, it is possible for a connection to be "half closed," 1350 i.e., closed in only one direction, and a host is permitted to 1351 continue sending data in the open direction on a half-closed 1352 connection. 1354 A host MAY implement a "half-duplex" TCP close sequence, so that an 1355 application that has called CLOSE cannot continue to read data from 1356 the connection. If such a host issues a CLOSE call while received 1357 data is still pending in TCP, or if new data is received after CLOSE 1358 is called, its TCP SHOULD send a RST to show that data was lost. 1360 When a connection is closed actively, it MUST linger in TIME-WAIT 1361 state for a time 2xMSL (Maximum Segment Lifetime). However, it MAY 1362 accept a new SYN from the remote TCP to reopen the connection 1363 directly from TIME-WAIT state, if it: 1365 (1) assigns its initial sequence number for the new connection to 1366 be larger than the largest sequence number it used on the previous 1367 connection incarnation, and 1369 (2) returns to TIME-WAIT state if the SYN turns out to be an old 1370 duplicate. 1372 3.6. Precedence and Security 1374 The intent is that connection be allowed only between ports operating 1375 with exactly the same security and compartment values and at the 1376 higher of the precedence level requested by the two ports. 1378 The precedence and security parameters used in TCP are exactly those 1379 defined in the Internet Protocol (IP) [2]. Throughout this TCP 1380 specification the term "security/compartment" is intended to indicate 1381 the security parameters used in IP including security, compartment, 1382 user group, and handling restriction. 1384 A connection attempt with mismatched security/compartment values or a 1385 lower precedence value must be rejected by sending a reset. 1386 Rejecting a connection due to too low a precedence only occurs after 1387 an acknowledgment of the SYN has been received. 1389 Note that TCP modules which operate only at the default value of 1390 precedence will still have to check the precedence of incoming 1391 segments and possibly raise the precedence level they use on the 1392 connection. 1394 The security parameters may be used even in a non-secure environment 1395 (the values would indicate unclassified data), thus hosts in non- 1396 secure environments must be prepared to receive the security 1397 parameters, though they need not send them. 1399 3.7. Segmentation 1401 The term "segmentation" refers to the activity TCP performs when 1402 ingesting a stream of bytes from a sending application and 1403 packetizing that stream of bytes into TCP segments. Individual TCP 1404 segments often do not correspond one-for-one to individual send (or 1405 socket write) calls from the application. Applications may perform 1406 writes at the granularity of messages in the upper layer protocol, 1407 but TCP guarantees no boundary coherence between the TCP segments 1408 sent and received versus user application data read or write buffer 1409 boundaries. In some specific protocols, such as RDMA using DDP and 1410 MPA [10], there are performance optimizations possible when the 1411 relation between TCP segments and application data units can be 1412 controlled, and MPA includes a specific mechanism for detecting and 1413 verifying this relationship between TCP segments and application 1414 message data strcutures, but this is specific to applications like 1415 RDMA. In general, multiple goals influence the sizing of TCP 1416 segments created by a TCP implementation. 1418 Goals driving the sending of larger segments include: 1420 o Reducing the number of packets in flight within the network. 1422 o Increasing processing efficiency and potential performance by 1423 enabling a smaller number of interrupts and inter-layer 1424 interactions. 1426 o Limiting the overhead of TCP headers. 1428 Note that the performance benefits of sending larger segments may 1429 decrease as the size increases, and there may be boundaries where 1430 advantages are reversed. For instance, on some machines 1025 bytes 1431 within a segment could lead to worse performance than 1024 bytes, due 1432 purely to data alignment on copy operations. 1434 Goals driving the sending of smaller segments include: 1436 o Avoiding sending segments larger than the smallest MTU within an 1437 IP network path, because this results in either packet loss or 1438 fragmentation. Making matters worse, some firewalls or 1439 middleboxes may drop fragmented packets or ICMP messages related 1440 related to fragmentation. 1442 o Preventing delays to the application data stream, especially when 1443 TCP is waiting on the application to generate more data, or when 1444 the application is waiting on an event or input from its peer in 1445 order to generate more data. 1447 o Enabling "fate sharing" between TCP segments and lower-layer data 1448 units (e.g. below IP, for links with cell or frame sizes smaller 1449 than the IP MTU). 1451 Towards meeting these competing sets of goals, TCP includes several 1452 mechanisms, including the Maximum Segment Size option, Path MTU 1453 Discovery, the Nagle algorithm, and support for IPv6 Jumbograms, as 1454 discussed in the following subsections. 1456 3.7.1. Maximum Segment Size Option 1458 TCP MUST implement both sending and receiving the MSS option. 1460 TCP SHOULD send an MSS option in every SYN segment when its receive 1461 MSS differs from the default 536 for IPv4 or 1220 for IPv6, and MAY 1462 send it always. 1464 If an MSS option is not received at connection setup, TCP MUST assume 1465 a default send MSS of 536 (576-40) for IPv4 or 1220 (1280 - 60) for 1466 IPv6. 1468 The maximum size of a segment that TCP really sends, the "effective 1469 send MSS," MUST be the smaller of the send MSS (which reflects the 1470 available reassembly buffer size at the remote host) and the largest 1471 size permitted by the IP layer: 1473 Eff.snd.MSS = 1475 min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize 1477 where: 1479 o SendMSS is the MSS value received from the remote host, or the 1480 default 536 for IPv4 or 1220 for IPv6, if no MSS option is 1481 received. 1483 o MMS_S is the maximum size for a transport-layer message that TCP 1484 may send. 1486 o TCPhdrsize is the size of the fixed TCP header and any options. 1487 This is 20 in the (rare) case that no options are present, but may 1488 be larger if TCP options are to be sent. Note that some options 1489 may not be included on all segments, but that for each segment 1490 sent, the sender should adjust the data length accordingly, within 1491 the Eff.snd.MSS. 1493 o IPoptionsize is the size of any IP options associated with a TCP 1494 connection. Note that some options may not be included on all 1495 packets, but that for each segment sent, the sender should adjust 1496 the data length accordingly, within the Eff.snd.MSS. 1498 The MSS value to be sent in an MSS option should be equal to the 1499 effective MTU minus the fixed IP and TCP headers. By ignoring both 1500 IP and TCP options when calculating the value for the MSS option, if 1501 there are any IP or TCP options to be sent in a packet, then the 1502 sender must decrease the size of the TCP data accordingly. RFC 6691 1503 [15] discusses this in greater detail. 1505 The MSS value to be sent in an MSS option must be less than or equal 1506 to: 1508 MMS_R - 20 1510 where MMS_R is the maximum size for a transport-layer message that 1511 can be received (and reassembled). TCP obtains MMS_R and MMS_S from 1512 the IP layer; see the generic call GET_MAXSIZES in Section 3.4 of RFC 1513 1122. 1515 When TCP is used in a situation where either the IP or TCP headers 1516 are not fixed, the sender must reduce the amount of TCP data in any 1517 given packet by the number of octets used by the IP and TCP options. 1518 This has been a point of confusion historically, as explained in RFC 1519 6691, Section 3.1. 1521 3.7.2. Path MTU Discovery 1523 A TCP implementation may be aware of the MTU on directly connected 1524 links, but will rarely have insight about MTUs across an entire 1525 network path. For IPv4, RFC 1122 provides an IP-layer recommendation 1526 on the default effective MTU for sending to be less than or equal to 1527 576 for destinations not directly connected. For IPv6, this would be 1528 1280. In all cases, however, implementation of Path MTU Discovery 1529 (PMTUD) and Packetization Layer Path MTU Discovery (PLPMTUD) is 1530 strongly recommended in order for TCP to improve segmentation 1531 decisions. 1533 PMTUD for IPv4 [1] or IPv6 [2] is implemented in conjunction between 1534 TCP, IP, and ICMP protocols. Several adjustments to a TCP 1535 implementation with PMTUD are described in RFC 2923 in order to deal 1536 with problems experienced in practice [5]. PLPMTUD [9] is a 1537 Standards Track improvement to PMTUD that relaxes the requirement for 1538 ICMP support across a path, and improves performance in cases where 1539 ICMP is not consistently conveyed. The mechanisms in all four of 1540 these RFCs are recommended to be included in TCP implementations. 1542 The TCP MSS option specifies an upper bound for the size of packets 1543 that can be received. Hence, setting the value in the MSS option too 1544 small can impact the ability for PMTUD or PLPMTUD to find a larger 1545 path MTU. RFC 1191 discusses this implication of many older TCP 1546 implementations setting MSS to 536 for non-local destinations, rather 1547 than deriving it from the MTUs of connected interfaces as 1548 recommended. 1550 3.7.3. Interfaces with Variable MTU Values 1552 The effective MTU can sometimes vary, as when used with variable 1553 compression, e.g., RObust Header Compression (ROHC) [12]. It is 1554 tempting for TCP to want to advertise the largest possible MSS, to 1555 support the most efficient use of compressed payloads. 1556 Unfortunately, some compression schemes occasionally need to transmit 1557 full headers (and thus smaller payloads) to resynchronize state at 1558 their endpoint compressors/decompressors. If the largest MTU is used 1559 to calculate the value to advertise in the MSS option, TCP 1560 retransmission may interfere with compressor resynchronization. 1562 As a result, when the effective MTU of an interface varies, TCP 1563 SHOULD use the smallest effective MTU of the interface to calculate 1564 the value to advertise in the MSS option. 1566 3.7.4. Nagle Algorithm 1568 The "Nagle algorithm" was described in RFC 896 [7] and was 1569 recommended in RFC 1122 [8] for mitigation of an early problem of too 1570 many small packets being generated. It has been implemented in most 1571 current TCP code bases, sometimes with minor variations. 1573 If there is unacknowledged data (i.e., SND.NXT > SND.UNA), then the 1574 sending TCP buffers all user data (regardless of the PSH bit), until 1575 the outstanding data has been acknowledged or until the TCP can send 1576 a full-sized segment (Eff.snd.MSS bytes). 1578 TODO - see if SEND description later should be updated to reflect 1579 this 1581 A TCP SHOULD implement the Nagle Algorithm to coalesce short 1582 segments. However, there MUST be a way for an application to disable 1583 the Nagle algorithm on an individual connection. In all cases, 1584 sending data is also subject to the limitation imposed by the Slow 1585 Start algorithm [11]. 1587 3.7.5. IPv6 Jumbograms 1589 In order to support TCP over IPv6 jumbograms, implementations need to 1590 be able to send TCP segments larger than the 64KB limit that the MSS 1591 option can convey. RFC 2675 [4] defines that an MSS value of 65,535 1592 bytes is to be treated as infinity, and Path MTU Discovery [2] is 1593 used to determine the actual MSS. 1595 3.8. Data Communication 1597 Once the connection is established data is communicated by the 1598 exchange of segments. Because segments may be lost due to errors 1599 (checksum test failure), or network congestion, TCP uses 1600 retransmission (after a timeout) to ensure delivery of every segment. 1601 Duplicate segments may arrive due to network or TCP retransmission. 1602 As discussed in the section on sequence numbers the TCP performs 1603 certain tests on the sequence and acknowledgment numbers in the 1604 segments to verify their acceptability. 1606 The sender of data keeps track of the next sequence number to use in 1607 the variable SND.NXT. The receiver of data keeps track of the next 1608 sequence number to expect in the variable RCV.NXT. The sender of 1609 data keeps track of the oldest unacknowledged sequence number in the 1610 variable SND.UNA. If the data flow is momentarily idle and all data 1611 sent has been acknowledged then the three variables will be equal. 1613 When the sender creates a segment and transmits it the sender 1614 advances SND.NXT. When the receiver accepts a segment it advances 1615 RCV.NXT and sends an acknowledgment. When the data sender receives 1616 an acknowledgment it advances SND.UNA. The extent to which the 1617 values of these variables differ is a measure of the delay in the 1618 communication. The amount by which the variables are advanced is the 1619 length of the data and SYN or FIN flags in the segment. Note that 1620 once in the ESTABLISHED state all segments must carry current 1621 acknowledgment information. 1623 The CLOSE user call implies a push function, as does the FIN control 1624 flag in an incoming segment. 1626 Retransmission Timeout 1628 NOTE: TODO this needs to be updated in light of 1122 4.2.2.15 and 1629 errata 573; this will be done as part of RFC 1122 incorporation into 1630 this document. 1631 Because of the variability of the networks that compose an 1632 internetwork system and the wide range of uses of TCP connections the 1633 retransmission timeout must be dynamically determined. One procedure 1634 for determining a retransmission timeout is given here as an 1635 illustration. 1637 An Example Retransmission Timeout Procedure 1639 Measure the elapsed time between sending a data octet with a 1640 particular sequence number and receiving an acknowledgment that 1641 covers that sequence number (segments sent do not have to match 1642 segments received). This measured elapsed time is the Round Trip 1643 Time (RTT). Next compute a Smoothed Round Trip Time (SRTT) as: 1645 SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT) 1647 and based on this, compute the retransmission timeout (RTO) as: 1649 RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]] 1651 where UBOUND is an upper bound on the timeout (e.g., 1 minute), 1652 LBOUND is a lower bound on the timeout (e.g., 1 second), ALPHA is 1653 a smoothing factor (e.g., .8 to .9), and BETA is a delay variance 1654 factor (e.g., 1.3 to 2.0). 1656 The Communication of Urgent Information 1658 As a result of implementation differences and middlebox interactions, 1659 new applications SHOULD NOT employ the TCP urgent mechanism. 1660 However, TCP implementations MUST still include support for the 1661 urgent mechanism. Details can be found in RFC 6093 [13]. 1663 The objective of the TCP urgent mechanism is to allow the sending 1664 user to stimulate the receiving user to accept some urgent data and 1665 to permit the receiving TCP to indicate to the receiving user when 1666 all the currently known urgent data has been received by the user. 1668 This mechanism permits a point in the data stream to be designated as 1669 the end of urgent information. Whenever this point is in advance of 1670 the receive sequence number (RCV.NXT) at the receiving TCP, that TCP 1671 must tell the user to go into "urgent mode"; when the receive 1672 sequence number catches up to the urgent pointer, the TCP must tell 1673 user to go into "normal mode". If the urgent pointer is updated 1674 while the user is in "urgent mode", the update will be invisible to 1675 the user. 1677 The method employs a urgent field which is carried in all segments 1678 transmitted. The URG control flag indicates that the urgent field is 1679 meaningful and must be added to the segment sequence number to yield 1680 the urgent pointer. The absence of this flag indicates that there is 1681 no urgent data outstanding. 1683 To send an urgent indication the user must also send at least one 1684 data octet. If the sending user also indicates a push, timely 1685 delivery of the urgent information to the destination process is 1686 enhanced. 1688 A TCP MUST support a sequence of urgent data of any length. [8] 1690 A TCP MUST inform the application layer asynchronously whenever it 1691 receives an Urgent pointer and there was previously no pending urgent 1692 data, or whenvever the Urgent pointer advances in the data stream. 1693 There MUST be a way for the application to learn how much urgent data 1694 remains to be read from the connection, or at least to determine 1695 whether or not more urgent data remains to be read. [8] 1697 Managing the Window 1699 The window sent in each segment indicates the range of sequence 1700 numbers the sender of the window (the data receiver) is currently 1701 prepared to accept. There is an assumption that this is related to 1702 the currently available data buffer space available for this 1703 connection. 1705 Indicating a large window encourages transmissions. If more data 1706 arrives than can be accepted, it will be discarded. This will result 1707 in excessive retransmissions, adding unnecessarily to the load on the 1708 network and the TCPs. Indicating a small window may restrict the 1709 transmission of data to the point of introducing a round trip delay 1710 between each new segment transmitted. 1712 The mechanisms provided allow a TCP to advertise a large window and 1713 to subsequently advertise a much smaller window without having 1714 accepted that much data. This, so called "shrinking the window," is 1715 strongly discouraged. The robustness principle dictates that TCPs 1716 will not shrink the window themselves, but will be prepared for such 1717 behavior on the part of other TCPs. 1719 The sending TCP must be prepared to accept from the user and send at 1720 least one octet of new data even if the send window is zero. The 1721 sending TCP must regularly retransmit to the receiving TCP even when 1722 the window is zero. Two minutes is recommended for the 1723 retransmission interval when the window is zero. This retransmission 1724 is essential to guarantee that when either TCP has a zero window the 1725 re-opening of the window will be reliably reported to the other. 1727 When the receiving TCP has a zero window and a segment arrives it 1728 must still send an acknowledgment showing its next expected sequence 1729 number and current window (zero). 1731 The sending TCP packages the data to be transmitted into segments 1732 which fit the current window, and may repackage segments on the 1733 retransmission queue. Such repackaging is not required, but may be 1734 helpful. 1736 In a connection with a one-way data flow, the window information will 1737 be carried in acknowledgment segments that all have the same sequence 1738 number so there will be no way to reorder them if they arrive out of 1739 order. This is not a serious problem, but it will allow the window 1740 information to be on occasion temporarily based on old reports from 1741 the data receiver. A refinement to avoid this problem is to act on 1742 the window information from segments that carry the highest 1743 acknowledgment number (that is segments with acknowledgment number 1744 equal or greater than the highest previously received). 1746 The window management procedure has significant influence on the 1747 communication performance. The following comments are suggestions to 1748 implementers. 1750 Window Management Suggestions 1752 Allocating a very small window causes data to be transmitted in 1753 many small segments when better performance is achieved using 1754 fewer large segments. 1756 One suggestion for avoiding small windows is for the receiver to 1757 defer updating a window until the additional allocation is at 1758 least X percent of the maximum allocation possible for the 1759 connection (where X might be 20 to 40). 1761 Another suggestion is for the sender to avoid sending small 1762 segments by waiting until the window is large enough before 1763 sending data. If the user signals a push function then the data 1764 must be sent even if it is a small segment. 1766 Note that the acknowledgments should not be delayed or unnecessary 1767 retransmissions will result. One strategy would be to send an 1768 acknowledgment when a small segment arrives (with out updating the 1769 window information), and then to send another acknowledgment with 1770 new window information when the window is larger. 1772 The segment sent to probe a zero window may also begin a break up 1773 of transmitted data into smaller and smaller segments. If a 1774 segment containing a single data octet sent to probe a zero window 1775 is accepted, it consumes one octet of the window now available. 1776 If the sending TCP simply sends as much as it can whenever the 1777 window is non zero, the transmitted data will be broken into 1778 alternating big and small segments. As time goes on, occasional 1779 pauses in the receiver making window allocation available will 1780 result in breaking the big segments into a small and not quite so 1781 big pair. And after a while the data transmission will be in 1782 mostly small segments. 1784 The suggestion here is that the TCP implementations need to 1785 actively attempt to combine small window allocations into larger 1786 windows, since the mechanisms for managing the window tend to lead 1787 to many small windows in the simplest minded implementations. 1789 3.9. Interfaces 1791 There are of course two interfaces of concern: the user/TCP interface 1792 and the TCP/lower-level interface. We have a fairly elaborate model 1793 of the user/TCP interface, but the interface to the lower level 1794 protocol module is left unspecified here, since it will be specified 1795 in detail by the specification of the lower level protocol. For the 1796 case that the lower level is IP we note some of the parameter values 1797 that TCPs might use. 1799 3.9.1. User/TCP Interface 1801 The following functional description of user commands to the TCP is, 1802 at best, fictional, since every operating system will have different 1803 facilities. Consequently, we must warn readers that different TCP 1804 implementations may have different user interfaces. However, all 1805 TCPs must provide a certain minimum set of services to guarantee that 1806 all TCP implementations can support the same protocol hierarchy. 1807 This section specifies the functional interfaces required of all TCP 1808 implementations. 1810 TCP User Commands 1812 The following sections functionally characterize a USER/TCP 1813 interface. The notation used is similar to most procedure or 1814 function calls in high level languages, but this usage is not 1815 meant to rule out trap type service calls (e.g., SVCs, UUOs, 1816 EMTs). 1818 The user commands described below specify the basic functions the 1819 TCP must perform to support interprocess communication. 1820 Individual implementations must define their own exact format, and 1821 may provide combinations or subsets of the basic functions in 1822 single calls. In particular, some implementations may wish to 1823 automatically OPEN a connection on the first SEND or RECEIVE 1824 issued by the user for a given connection. 1826 In providing interprocess communication facilities, the TCP must 1827 not only accept commands, but must also return information to the 1828 processes it serves. The latter consists of: 1830 (a) general information about a connection (e.g., interrupts, 1831 remote close, binding of unspecified foreign socket). 1833 (b) replies to specific user commands indicating success or 1834 various types of failure. 1836 Open 1838 Format: OPEN (local port, foreign socket, active/passive [, 1839 timeout] [, precedence] [, security/compartment] [local IP 1840 address,] [, options]) -> local connection name 1842 We assume that the local TCP is aware of the identity of the 1843 processes it serves and will check the authority of the process 1844 to use the connection specified. Depending upon the 1845 implementation of the TCP, the local network and TCP 1846 identifiers for the source address will either be supplied by 1847 the TCP or the lower level protocol (e.g., IP). These 1848 considerations are the result of concern about security, to the 1849 extent that no TCP be able to masquerade as another one, and so 1850 on. Similarly, no process can masquerade as another without 1851 the collusion of the TCP. 1853 If the active/passive flag is set to passive, then this is a 1854 call to LISTEN for an incoming connection. A passive open may 1855 have either a fully specified foreign socket to wait for a 1856 particular connection or an unspecified foreign socket to wait 1857 for any call. A fully specified passive call can be made 1858 active by the subsequent execution of a SEND. 1860 A transmission control block (TCB) is created and partially 1861 filled in with data from the OPEN command parameters. 1863 On an active OPEN command, the TCP will begin the procedure to 1864 synchronize (i.e., establish) the connection at once. 1866 The timeout, if present, permits the caller to set up a timeout 1867 for all data submitted to TCP. If data is not successfully 1868 delivered to the destination within the timeout period, the TCP 1869 will abort the connection. The present global default is five 1870 minutes. 1872 The TCP or some component of the operating system will verify 1873 the users authority to open a connection with the specified 1874 precedence or security/compartment. The absence of precedence 1875 or security/compartment specification in the OPEN call 1876 indicates the default values must be used. 1878 TCP will accept incoming requests as matching only if the 1879 security/compartment information is exactly the same and only 1880 if the precedence is equal to or higher than the precedence 1881 requested in the OPEN call. 1883 The precedence for the connection is the higher of the values 1884 requested in the OPEN call and received from the incoming 1885 request, and fixed at that value for the life of the 1886 connection.Implementers may want to give the user control of 1887 this precedence negotiation. For example, the user might be 1888 allowed to specify that the precedence must be exactly matched, 1889 or that any attempt to raise the precedence be confirmed by the 1890 user. 1892 A local connection name will be returned to the user by the 1893 TCP. The local connection name can then be used as a short 1894 hand term for the connection defined by the pair. 1897 The optional "local IP address" parameter MUST be supported to 1898 allow the specification of the local IP address. This enables 1899 applications that need to select the local IP address used when 1900 multihoming is present. 1902 A passive OPEN call with a specified "local IP address" 1903 parameter will await an incoming connection request to that 1904 address. If the parameter is unspecified, a passive OPEN will 1905 await an incoming connection request to any local IP address, 1906 and then bind the local IP address of the connection to the 1907 particular address that is used. 1909 For an active OPEN call, a specified "local IP address" 1910 parameter will be used for opening the connection. If the 1911 parameter is unspecified, the TCP will choose an appropriate 1912 local IP address (see RFC 1122 section 3.3.4.2). 1914 Send 1916 Format: SEND (local connection name, buffer address, byte 1917 count, PUSH flag, URGENT flag [,timeout]) 1919 This call causes the data contained in the indicated user 1920 buffer to be sent on the indicated connection. If the 1921 connection has not been opened, the SEND is considered an 1922 error. Some implementations may allow users to SEND first; in 1923 which case, an automatic OPEN would be done. If the calling 1924 process is not authorized to use this connection, an error is 1925 returned. 1927 If the PUSH flag is set, the data must be transmitted promptly 1928 to the receiver, and the PUSH bit will be set in the last TCP 1929 segment created from the buffer. If the PUSH flag is not set, 1930 the data may be combined with data from subsequent SENDs for 1931 transmission efficiency. 1933 New applications SHOULD NOT set the URGENT flag [13] due to 1934 implementation differences and middlebox issues. 1936 If the URGENT flag is set, segments sent to the destination TCP 1937 will have the urgent pointer set. The receiving TCP will 1938 signal the urgent condition to the receiving process if the 1939 urgent pointer indicates that data preceding the urgent pointer 1940 has not been consumed by the receiving process. The purpose of 1941 urgent is to stimulate the receiver to process the urgent data 1942 and to indicate to the receiver when all the currently known 1943 urgent data has been received. The number of times the sending 1944 user's TCP signals urgent will not necessarily be equal to the 1945 number of times the receiving user will be notified of the 1946 presence of urgent data. 1948 If no foreign socket was specified in the OPEN, but the 1949 connection is established (e.g., because a LISTENing connection 1950 has become specific due to a foreign segment arriving for the 1951 local socket), then the designated buffer is sent to the 1952 implied foreign socket. Users who make use of OPEN with an 1953 unspecified foreign socket can make use of SEND without ever 1954 explicitly knowing the foreign socket address. 1956 However, if a SEND is attempted before the foreign socket 1957 becomes specified, an error will be returned. Users can use 1958 the STATUS call to determine the status of the connection. In 1959 some implementations the TCP may notify the user when an 1960 unspecified socket is bound. 1962 If a timeout is specified, the current user timeout for this 1963 connection is changed to the new one. 1965 In the simplest implementation, SEND would not return control 1966 to the sending process until either the transmission was 1967 complete or the timeout had been exceeded. However, this 1968 simple method is both subject to deadlocks (for example, both 1969 sides of the connection might try to do SENDs before doing any 1970 RECEIVEs) and offers poor performance, so it is not 1971 recommended. A more sophisticated implementation would return 1972 immediately to allow the process to run concurrently with 1973 network I/O, and, furthermore, to allow multiple SENDs to be in 1974 progress. Multiple SENDs are served in first come, first 1975 served order, so the TCP will queue those it cannot service 1976 immediately. 1978 We have implicitly assumed an asynchronous user interface in 1979 which a SEND later elicits some kind of SIGNAL or pseudo- 1980 interrupt from the serving TCP. An alternative is to return a 1981 response immediately. For instance, SENDs might return 1982 immediate local acknowledgment, even if the segment sent had 1983 not been acknowledged by the distant TCP. We could 1984 optimistically assume eventual success. If we are wrong, the 1985 connection will close anyway due to the timeout. In 1986 implementations of this kind (synchronous), there will still be 1987 some asynchronous signals, but these will deal with the 1988 connection itself, and not with specific segments or buffers. 1990 In order for the process to distinguish among error or success 1991 indications for different SENDs, it might be appropriate for 1992 the buffer address to be returned along with the coded response 1993 to the SEND request. TCP-to-user signals are discussed below, 1994 indicating the information which should be returned to the 1995 calling process. 1997 Receive 1999 Format: RECEIVE (local connection name, buffer address, byte 2000 count) -> byte count, urgent flag, push flag 2002 This command allocates a receiving buffer associated with the 2003 specified connection. If no OPEN precedes this command or the 2004 calling process is not authorized to use this connection, an 2005 error is returned. 2007 In the simplest implementation, control would not return to the 2008 calling program until either the buffer was filled, or some 2009 error occurred, but this scheme is highly subject to deadlocks. 2011 A more sophisticated implementation would permit several 2012 RECEIVEs to be outstanding at once. These would be filled as 2013 segments arrive. This strategy permits increased throughput at 2014 the cost of a more elaborate scheme (possibly asynchronous) to 2015 notify the calling program that a PUSH has been seen or a 2016 buffer filled. 2018 If enough data arrive to fill the buffer before a PUSH is seen, 2019 the PUSH flag will not be set in the response to the RECEIVE. 2020 The buffer will be filled with as much data as it can hold. If 2021 a PUSH is seen before the buffer is filled the buffer will be 2022 returned partially filled and PUSH indicated. 2024 If there is urgent data the user will have been informed as 2025 soon as it arrived via a TCP-to-user signal. The receiving 2026 user should thus be in "urgent mode". If the URGENT flag is 2027 on, additional urgent data remains. If the URGENT flag is off, 2028 this call to RECEIVE has returned all the urgent data, and the 2029 user may now leave "urgent mode". Note that data following the 2030 urgent pointer (non-urgent data) cannot be delivered to the 2031 user in the same buffer with preceding urgent data unless the 2032 boundary is clearly marked for the user. 2034 To distinguish among several outstanding RECEIVEs and to take 2035 care of the case that a buffer is not completely filled, the 2036 return code is accompanied by both a buffer pointer and a byte 2037 count indicating the actual length of the data received. 2039 Alternative implementations of RECEIVE might have the TCP 2040 allocate buffer storage, or the TCP might share a ring buffer 2041 with the user. 2043 Close 2045 Format: CLOSE (local connection name) 2047 This command causes the connection specified to be closed. If 2048 the connection is not open or the calling process is not 2049 authorized to use this connection, an error is returned. 2050 Closing connections is intended to be a graceful operation in 2051 the sense that outstanding SENDs will be transmitted (and 2052 retransmitted), as flow control permits, until all have been 2053 serviced. Thus, it should be acceptable to make several SEND 2054 calls, followed by a CLOSE, and expect all the data to be sent 2055 to the destination. It should also be clear that users should 2056 continue to RECEIVE on CLOSING connections, since the other 2057 side may be trying to transmit the last of its data. Thus, 2058 CLOSE means "I have no more to send" but does not mean "I will 2059 not receive any more." It may happen (if the user level 2060 protocol is not well thought out) that the closing side is 2061 unable to get rid of all its data before timing out. In this 2062 event, CLOSE turns into ABORT, and the closing TCP gives up. 2064 The user may CLOSE the connection at any time on his own 2065 initiative, or in response to various prompts from the TCP 2066 (e.g., remote close executed, transmission timeout exceeded, 2067 destination inaccessible). 2069 Because closing a connection requires communication with the 2070 foreign TCP, connections may remain in the closing state for a 2071 short time. Attempts to reopen the connection before the TCP 2072 replies to the CLOSE command will result in error responses. 2074 Close also implies push function. 2076 Status 2078 Format: STATUS (local connection name) -> status data 2080 This is an implementation dependent user command and could be 2081 excluded without adverse effect. Information returned would 2082 typically come from the TCB associated with the connection. 2084 This command returns a data block containing the following 2085 information: 2087 local socket, 2088 foreign socket, 2089 local connection name, 2090 receive window, 2091 send window, 2092 connection state, 2093 number of buffers awaiting acknowledgment, 2094 number of buffers pending receipt, 2095 urgent state, 2096 precedence, 2097 security/compartment, 2098 and transmission timeout. 2100 Depending on the state of the connection, or on the 2101 implementation itself, some of this information may not be 2102 available or meaningful. If the calling process is not 2103 authorized to use this connection, an error is returned. This 2104 prevents unauthorized processes from gaining information about 2105 a connection. 2107 Abort 2109 Format: ABORT (local connection name) 2111 This command causes all pending SENDs and RECEIVES to be 2112 aborted, the TCB to be removed, and a special RESET message to 2113 be sent to the TCP on the other side of the connection. 2114 Depending on the implementation, users may receive abort 2115 indications for each outstanding SEND or RECEIVE, or may simply 2116 receive an ABORT-acknowledgment. 2118 Flush 2120 Some TCP implementations have included a FLUSH call, which will 2121 empty the TCP send queue of any data for which the user has 2122 issued SEND calls but which is still to the right of the 2123 current send window. That is, it flushes as much queued send 2124 data as possible without losing sequence number 2125 synchronization. 2127 Set TOS 2129 The application layer MUST be able to specify the Type-of- 2130 Service (TOS) for segments that are sent on a connection. It 2131 not required, but the application SHOULD be able to change the 2132 TOS during the connection lifetime. TCP SHOULD pass the 2133 current TOS value without change to the IP layer, when it sends 2134 segments on the connection. 2136 The TOS will be specified independently in each direction on 2137 the connection, so that the receiver application will specify 2138 the TOS used for ACK segments. 2140 TCP MAY pass the most recently received TOS up to the 2141 application. 2143 TCP-to-User Messages 2145 It is assumed that the operating system environment provides a 2146 means for the TCP to asynchronously signal the user program. 2147 When the TCP does signal a user program, certain information is 2148 passed to the user. Often in the specification the information 2149 will be an error message. In other cases there will be 2150 information relating to the completion of processing a SEND or 2151 RECEIVE or other user call. 2153 The following information is provided: 2155 Local Connection Name Always 2156 Response String Always 2157 Buffer Address Send & Receive 2158 Byte count (counts bytes received) Receive 2159 Push flag Receive 2160 Urgent flag Receive 2162 3.9.2. TCP/Lower-Level Interface 2164 The TCP calls on a lower level protocol module to actually send and 2165 receive information over a network. One case is that of the ARPA 2166 internetwork system where the lower level module is the Internet 2167 Protocol (IP) [2]. 2169 If the lower level protocol is IP it provides arguments for a type of 2170 service and for a time to live. TCP uses the following settings for 2171 these parameters: 2173 Type of Service = Precedence: given by user, Delay: normal, 2174 Throughput: normal, Reliability: normal; or binary XXX00000, where 2175 XXX are the three bits determining precedence, e.g. 000 means 2176 routine precedence. 2178 Time to Live = one minute, or 00111100. 2180 Note that the assumed maximum segment lifetime is two minutes. 2181 Here we explicitly ask that a segment be destroyed if it cannot 2182 be delivered by the internet system within one minute. 2184 If the lower level is IP (or other protocol that provides this 2185 feature) and source routing is used, the interface must allow the 2186 route information to be communicated. This is especially important 2187 so that the source and destination addresses used in the TCP checksum 2188 be the originating source and ultimate destination. It is also 2189 important to preserve the return route to answer connection requests. 2191 Any lower level protocol will have to provide the source address, 2192 destination address, and protocol fields, and some way to determine 2193 the "TCP length", both to provide the functional equivalent service 2194 of IP and to be used in the TCP checksum. 2196 3.10. Event Processing 2198 The processing depicted in this section is an example of one possible 2199 implementation. Other implementations may have slightly different 2200 processing sequences, but they should differ from those in this 2201 section only in detail, not in substance. 2203 The activity of the TCP can be characterized as responding to events. 2204 The events that occur can be cast into three categories: user calls, 2205 arriving segments, and timeouts. This section describes the 2206 processing the TCP does in response to each of the events. In many 2207 cases the processing required depends on the state of the connection. 2209 Events that occur: 2211 User Calls 2213 OPEN 2214 SEND 2215 RECEIVE 2216 CLOSE 2217 ABORT 2218 STATUS 2220 Arriving Segments 2222 SEGMENT ARRIVES 2224 Timeouts 2226 USER TIMEOUT 2227 RETRANSMISSION TIMEOUT 2228 TIME-WAIT TIMEOUT 2230 The model of the TCP/user interface is that user commands receive an 2231 immediate return and possibly a delayed response via an event or 2232 pseudo interrupt. In the following descriptions, the term "signal" 2233 means cause a delayed response. 2235 Error responses are given as character strings. For example, user 2236 commands referencing connections that do not exist receive "error: 2237 connection not open". 2239 Please note in the following that all arithmetic on sequence numbers, 2240 acknowledgment numbers, windows, et cetera, is modulo 2**32 the size 2241 of the sequence number space. Also note that "=<" means less than or 2242 equal to (modulo 2**32). 2244 A natural way to think about processing incoming segments is to 2245 imagine that they are first tested for proper sequence number (i.e., 2246 that their contents lie in the range of the expected "receive window" 2247 in the sequence number space) and then that they are generally queued 2248 and processed in sequence number order. 2250 When a segment overlaps other already received segments we 2251 reconstruct the segment to contain just the new data, and adjust the 2252 header fields to be consistent. 2254 Note that if no state change is mentioned the TCP stays in the same 2255 state. 2257 OPEN Call 2259 CLOSED STATE (i.e., TCB does not exist) 2261 Create a new transmission control block (TCB) to hold 2262 connection state information. Fill in local socket identifier, 2263 foreign socket, precedence, security/compartment, and user 2264 timeout information. Note that some parts of the foreign 2265 socket may be unspecified in a passive OPEN and are to be 2266 filled in by the parameters of the incoming SYN segment. 2267 Verify the security and precedence requested are allowed for 2268 this user, if not return "error: precedence not allowed" or 2269 "error: security/compartment not allowed." If passive enter 2270 the LISTEN state and return. If active and the foreign socket 2271 is unspecified, return "error: foreign socket unspecified"; if 2272 active and the foreign socket is specified, issue a SYN 2273 segment. An initial send sequence number (ISS) is selected. A 2274 SYN segment of the form is sent. Set 2275 SND.UNA to ISS, SND.NXT to ISS+1, enter SYN-SENT state, and 2276 return. 2278 If the caller does not have access to the local socket 2279 specified, return "error: connection illegal for this process". 2280 If there is no room to create a new connection, return "error: 2281 insufficient resources". 2283 LISTEN STATE 2285 If active and the foreign socket is specified, then change the 2286 connection from passive to active, select an ISS. Send a SYN 2287 segment, set SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT 2288 state. Data associated with SEND may be sent with SYN segment 2289 or queued for transmission after entering ESTABLISHED state. 2290 The urgent bit if requested in the command must be sent with 2291 the data segments sent as a result of this command. If there 2292 is no room to queue the request, respond with "error: 2293 insufficient resources". If Foreign socket was not specified, 2294 then return "error: foreign socket unspecified". 2296 SYN-SENT STATE 2297 SYN-RECEIVED STATE 2298 ESTABLISHED STATE 2299 FIN-WAIT-1 STATE 2300 FIN-WAIT-2 STATE 2301 CLOSE-WAIT STATE 2302 CLOSING STATE 2303 LAST-ACK STATE 2304 TIME-WAIT STATE 2306 Return "error: connection already exists". 2308 SEND Call 2310 CLOSED STATE (i.e., TCB does not exist) 2312 If the user does not have access to such a connection, then 2313 return "error: connection illegal for this process". 2315 Otherwise, return "error: connection does not exist". 2317 LISTEN STATE 2319 If the foreign socket is specified, then change the connection 2320 from passive to active, select an ISS. Send a SYN segment, set 2321 SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. Data 2322 associated with SEND may be sent with SYN segment or queued for 2323 transmission after entering ESTABLISHED state. The urgent bit 2324 if requested in the command must be sent with the data segments 2325 sent as a result of this command. If there is no room to queue 2326 the request, respond with "error: insufficient resources". If 2327 Foreign socket was not specified, then return "error: foreign 2328 socket unspecified". 2330 SYN-SENT STATE 2331 SYN-RECEIVED STATE 2333 Queue the data for transmission after entering ESTABLISHED 2334 state. If no space to queue, respond with "error: insufficient 2335 resources". 2337 ESTABLISHED STATE 2338 CLOSE-WAIT STATE 2340 Segmentize the buffer and send it with a piggybacked 2341 acknowledgment (acknowledgment value = RCV.NXT). If there is 2342 insufficient space to remember this buffer, simply return 2343 "error: insufficient resources". 2345 If the urgent flag is set, then SND.UP <- SND.NXT and set the 2346 urgent pointer in the outgoing segments. 2348 FIN-WAIT-1 STATE 2349 FIN-WAIT-2 STATE 2350 CLOSING STATE 2351 LAST-ACK STATE 2352 TIME-WAIT STATE 2354 Return "error: connection closing" and do not service request. 2356 RECEIVE Call 2358 CLOSED STATE (i.e., TCB does not exist) 2360 If the user does not have access to such a connection, return 2361 "error: connection illegal for this process". 2363 Otherwise return "error: connection does not exist". 2365 LISTEN STATE 2366 SYN-SENT STATE 2367 SYN-RECEIVED STATE 2369 Queue for processing after entering ESTABLISHED state. If 2370 there is no room to queue this request, respond with "error: 2371 insufficient resources". 2373 ESTABLISHED STATE 2374 FIN-WAIT-1 STATE 2375 FIN-WAIT-2 STATE 2377 If insufficient incoming segments are queued to satisfy the 2378 request, queue the request. If there is no queue space to 2379 remember the RECEIVE, respond with "error: insufficient 2380 resources". 2382 Reassemble queued incoming segments into receive buffer and 2383 return to user. Mark "push seen" (PUSH) if this is the case. 2385 If RCV.UP is in advance of the data currently being passed to 2386 the user notify the user of the presence of urgent data. 2388 When the TCP takes responsibility for delivering data to the 2389 user that fact must be communicated to the sender via an 2390 acknowledgment. The formation of such an acknowledgment is 2391 described below in the discussion of processing an incoming 2392 segment. 2394 CLOSE-WAIT STATE 2396 Since the remote side has already sent FIN, RECEIVEs must be 2397 satisfied by text already on hand, but not yet delivered to the 2398 user. If no text is awaiting delivery, the RECEIVE will get a 2399 "error: connection closing" response. Otherwise, any remaining 2400 text can be used to satisfy the RECEIVE. 2402 CLOSING STATE 2403 LAST-ACK STATE 2404 TIME-WAIT STATE 2406 Return "error: connection closing". 2408 CLOSE Call 2410 CLOSED STATE (i.e., TCB does not exist) 2412 If the user does not have access to such a connection, return 2413 "error: connection illegal for this process". 2415 Otherwise, return "error: connection does not exist". 2417 LISTEN STATE 2419 Any outstanding RECEIVEs are returned with "error: closing" 2420 responses. Delete TCB, enter CLOSED state, and return. 2422 SYN-SENT STATE 2424 Delete the TCB and return "error: closing" responses to any 2425 queued SENDs, or RECEIVEs. 2427 SYN-RECEIVED STATE 2429 If no SENDs have been issued and there is no pending data to 2430 send, then form a FIN segment and send it, and enter FIN-WAIT-1 2431 state; otherwise queue for processing after entering 2432 ESTABLISHED state. 2434 ESTABLISHED STATE 2436 Queue this until all preceding SENDs have been segmentized, 2437 then form a FIN segment and send it. In any case, enter FIN- 2438 WAIT-1 state. 2440 FIN-WAIT-1 STATE 2441 FIN-WAIT-2 STATE 2443 Strictly speaking, this is an error and should receive a 2444 "error: connection closing" response. An "ok" response would 2445 be acceptable, too, as long as a second FIN is not emitted (the 2446 first FIN may be retransmitted though). 2448 CLOSE-WAIT STATE 2450 Queue this request until all preceding SENDs have been 2451 segmentized; then send a FIN segment, enter LAST-ACK state. 2453 CLOSING STATE 2454 LAST-ACK STATE 2455 TIME-WAIT STATE 2456 Respond with "error: connection closing". 2458 ABORT Call 2460 CLOSED STATE (i.e., TCB does not exist) 2462 If the user should not have access to such a connection, return 2463 "error: connection illegal for this process". 2465 Otherwise return "error: connection does not exist". 2467 LISTEN STATE 2469 Any outstanding RECEIVEs should be returned with "error: 2470 connection reset" responses. Delete TCB, enter CLOSED state, 2471 and return. 2473 SYN-SENT STATE 2475 All queued SENDs and RECEIVEs should be given "connection 2476 reset" notification, delete the TCB, enter CLOSED state, and 2477 return. 2479 SYN-RECEIVED STATE 2480 ESTABLISHED STATE 2481 FIN-WAIT-1 STATE 2482 FIN-WAIT-2 STATE 2483 CLOSE-WAIT STATE 2485 Send a reset segment: 2487 2489 All queued SENDs and RECEIVEs should be given "connection 2490 reset" notification; all segments queued for transmission 2491 (except for the RST formed above) or retransmission should be 2492 flushed, delete the TCB, enter CLOSED state, and return. 2494 CLOSING STATE LAST-ACK STATE TIME-WAIT STATE 2496 Respond with "ok" and delete the TCB, enter CLOSED state, and 2497 return. 2499 STATUS Call 2501 CLOSED STATE (i.e., TCB does not exist) 2503 If the user should not have access to such a connection, return 2504 "error: connection illegal for this process". 2506 Otherwise return "error: connection does not exist". 2508 LISTEN STATE 2510 Return "state = LISTEN", and the TCB pointer. 2512 SYN-SENT STATE 2514 Return "state = SYN-SENT", and the TCB pointer. 2516 SYN-RECEIVED STATE 2518 Return "state = SYN-RECEIVED", and the TCB pointer. 2520 ESTABLISHED STATE 2522 Return "state = ESTABLISHED", and the TCB pointer. 2524 FIN-WAIT-1 STATE 2526 Return "state = FIN-WAIT-1", and the TCB pointer. 2528 FIN-WAIT-2 STATE 2530 Return "state = FIN-WAIT-2", and the TCB pointer. 2532 CLOSE-WAIT STATE 2534 Return "state = CLOSE-WAIT", and the TCB pointer. 2536 CLOSING STATE 2538 Return "state = CLOSING", and the TCB pointer. 2540 LAST-ACK STATE 2542 Return "state = LAST-ACK", and the TCB pointer. 2544 TIME-WAIT STATE 2546 Return "state = TIME-WAIT", and the TCB pointer. 2548 SEGMENT ARRIVES 2550 If the state is CLOSED (i.e., TCB does not exist) then 2552 all data in the incoming segment is discarded. An incoming 2553 segment containing a RST is discarded. An incoming segment not 2554 containing a RST causes a RST to be sent in response. The 2555 acknowledgment and sequence field values are selected to make 2556 the reset sequence acceptable to the TCP that sent the 2557 offending segment. 2559 If the ACK bit is off, sequence number zero is used, 2561 2563 If the ACK bit is on, 2565 2567 Return. 2569 If the state is LISTEN then 2571 first check for an RST 2573 An incoming RST should be ignored. Return. 2575 second check for an ACK 2577 Any acknowledgment is bad if it arrives on a connection 2578 still in the LISTEN state. An acceptable reset segment 2579 should be formed for any arriving ACK-bearing segment. The 2580 RST should be formatted as follows: 2582 2584 Return. 2586 third check for a SYN 2588 If the SYN bit is set, check the security. If the security/ 2589 compartment on the incoming segment does not exactly match 2590 the security/compartment in the TCB then send a reset and 2591 return. 2593 2595 If the SEG.PRC is greater than the TCB.PRC then if allowed 2596 by the user and the system set TCB.PRC<-SEG.PRC, if not 2597 allowed send a reset and return. 2599 2601 If the SEG.PRC is less than the TCB.PRC then continue. 2603 Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any 2604 other control or text should be queued for processing later. 2605 ISS should be selected and a SYN segment sent of the form: 2607 2609 SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection 2610 state should be changed to SYN-RECEIVED. Note that any 2611 other incoming control or data (combined with SYN) will be 2612 processed in the SYN-RECEIVED state, but processing of SYN 2613 and ACK should not be repeated. If the listen was not fully 2614 specified (i.e., the foreign socket was not fully 2615 specified), then the unspecified fields should be filled in 2616 now. 2618 fourth other text or control 2620 Any other control or text-bearing segment (not containing 2621 SYN) must have an ACK and thus would be discarded by the ACK 2622 processing. An incoming RST segment could not be valid, 2623 since it could not have been sent in response to anything 2624 sent by this incarnation of the connection. So you are 2625 unlikely to get here, but if you do, drop the segment, and 2626 return. 2628 If the state is SYN-SENT then 2630 first check the ACK bit 2632 If the ACK bit is set 2634 If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset 2635 (unless the RST bit is set, if so drop the segment and 2636 return) 2638 2640 and discard the segment. Return. 2642 If SND.UNA < SEG.ACK =< SND.NXT then the ACK is 2643 acceptable. (TODO: in processing Errata ID 3300, it was 2644 noted that some stacks in the wild that do not send data 2645 on the SYN are just checking that SEG.ACK == SND.NXT ... 2646 think about whether anything should be said about that 2647 here) 2649 second check the RST bit 2651 If the RST bit is set 2653 If the ACK was acceptable then signal the user "error: 2654 connection reset", drop the segment, enter CLOSED state, 2655 delete TCB, and return. Otherwise (no ACK) drop the 2656 segment and return. 2658 third check the security and precedence 2660 If the security/compartment in the segment does not exactly 2661 match the security/compartment in the TCB, send a reset 2663 If there is an ACK 2665 2667 Otherwise 2669 2671 If there is an ACK 2673 The precedence in the segment must match the precedence 2674 in the TCB, if not, send a reset 2676 2678 If there is no ACK 2680 If the precedence in the segment is higher than the 2681 precedence in the TCB then if allowed by the user and the 2682 system raise the precedence in the TCB to that in the 2683 segment, if not allowed to raise the prec then send a 2684 reset. 2686 2688 If the precedence in the segment is lower than the 2689 precedence in the TCB continue. 2691 If a reset was sent, discard the segment and return. 2693 fourth check the SYN bit 2695 This step should be reached only if the ACK is ok, or there 2696 is no ACK, and it the segment did not contain a RST. 2698 If the SYN bit is on and the security/compartment and 2699 precedence are acceptable then, RCV.NXT is set to SEG.SEQ+1, 2700 IRS is set to SEG.SEQ. SND.UNA should be advanced to equal 2701 SEG.ACK (if there is an ACK), and any segments on the 2702 retransmission queue which are thereby acknowledged should 2703 be removed. 2705 If SND.UNA > ISS (our SYN has been ACKed), change the 2706 connection state to ESTABLISHED, form an ACK segment 2708 2710 and send it. Data or controls which were queued for 2711 transmission may be included. If there are other controls 2712 or text in the segment then continue processing at the sixth 2713 step below where the URG bit is checked, otherwise return. 2715 Otherwise enter SYN-RECEIVED, form a SYN,ACK segment 2717 2719 and send it. Set the variables: 2721 SND.WND <- SEG.WND 2722 SND.WL1 <- SEG.SEQ 2723 SND.WL2 <- SEG.ACK 2725 If there are other controls or text in the segment, queue 2726 them for processing after the ESTABLISHED state has been 2727 reached, return. 2729 fifth, if neither of the SYN or RST bits is set then drop the 2730 segment and return. 2732 Otherwise, 2734 first check sequence number 2736 SYN-RECEIVED STATE 2737 ESTABLISHED STATE 2738 FIN-WAIT-1 STATE 2739 FIN-WAIT-2 STATE 2740 CLOSE-WAIT STATE 2741 CLOSING STATE 2742 LAST-ACK STATE 2743 TIME-WAIT STATE 2745 Segments are processed in sequence. Initial tests on 2746 arrival are used to discard old duplicates, but further 2747 processing is done in SEG.SEQ order. If a segment's 2748 contents straddle the boundary between old and new, only the 2749 new parts should be processed. 2751 There are four cases for the acceptability test for an 2752 incoming segment: 2754 Segment Receive Test 2755 Length Window 2756 ------- ------- ------------------------------------------- 2758 0 0 SEG.SEQ = RCV.NXT 2760 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 2762 >0 0 not acceptable 2764 >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 2765 or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 2767 If the RCV.WND is zero, no segments will be acceptable, but 2768 special allowance should be made to accept valid ACKs, URGs 2769 and RSTs. 2771 If an incoming segment is not acceptable, an acknowledgment 2772 should be sent in reply (unless the RST bit is set, if so 2773 drop the segment and return): 2775 2777 After sending the acknowledgment, drop the unacceptable 2778 segment and return. 2780 In the following it is assumed that the segment is the 2781 idealized segment that begins at RCV.NXT and does not exceed 2782 the window. One could tailor actual segments to fit this 2783 assumption by trimming off any portions that lie outside the 2784 window (including SYN and FIN), and only processing further 2785 if the segment then begins at RCV.NXT. Segments with higher 2786 beginning sequence numbers should be held for later 2787 processing. 2789 second check the RST bit, 2791 SYN-RECEIVED STATE 2793 If the RST bit is set 2795 If this connection was initiated with a passive OPEN 2796 (i.e., came from the LISTEN state), then return this 2797 connection to LISTEN state and return. The user need 2798 not be informed. If this connection was initiated 2799 with an active OPEN (i.e., came from SYN-SENT state) 2800 then the connection was refused, signal the user 2801 "connection refused". In either case, all segments on 2802 the retransmission queue should be removed. And in 2803 the active OPEN case, enter the CLOSED state and 2804 delete the TCB, and return. 2806 ESTABLISHED 2807 FIN-WAIT-1 2808 FIN-WAIT-2 2809 CLOSE-WAIT 2811 If the RST bit is set then, any outstanding RECEIVEs and 2812 SEND should receive "reset" responses. All segment 2813 queues should be flushed. Users should also receive an 2814 unsolicited general "connection reset" signal. Enter the 2815 CLOSED state, delete the TCB, and return. 2817 CLOSING STATE 2818 LAST-ACK STATE 2819 TIME-WAIT 2821 If the RST bit is set then, enter the CLOSED state, 2822 delete the TCB, and return. 2824 third check security and precedence 2826 SYN-RECEIVED 2828 If the security/compartment and precedence in the segment 2829 do not exactly match the security/compartment and 2830 precedence in the TCB then send a reset, and return. 2832 ESTABLISHED 2833 FIN-WAIT-1 2834 FIN-WAIT-2 2835 CLOSE-WAIT 2836 CLOSING 2837 LAST-ACK 2838 TIME-WAIT 2840 If the security/compartment and precedence in the segment 2841 do not exactly match the security/compartment and 2842 precedence in the TCB then send a reset, any outstanding 2843 RECEIVEs and SEND should receive "reset" responses. All 2844 segment queues should be flushed. Users should also 2845 receive an unsolicited general "connection reset" signal. 2846 Enter the CLOSED state, delete the TCB, and return. 2848 Note this check is placed following the sequence check to 2849 prevent a segment from an old connection between these ports 2850 with a different security or precedence from causing an 2851 abort of the current connection. 2853 fourth, check the SYN bit, 2855 SYN-RECEIVED 2856 ESTABLISHED STATE 2857 FIN-WAIT STATE-1 2858 FIN-WAIT STATE-2 2859 CLOSE-WAIT STATE 2860 CLOSING STATE 2861 LAST-ACK STATE 2862 TIME-WAIT STATE 2864 TODO: need to incorporate RFC 1122 4.2.2.20(e) here 2866 If the SYN is in the window it is an error, send a reset, 2867 any outstanding RECEIVEs and SEND should receive "reset" 2868 responses, all segment queues should be flushed, the user 2869 should also receive an unsolicited general "connection 2870 reset" signal, enter the CLOSED state, delete the TCB, 2871 and return. 2873 If the SYN is not in the window this step would not be 2874 reached and an ack would have been sent in the first step 2875 (sequence number check). 2877 fifth check the ACK field, 2879 if the ACK bit is off drop the segment and return 2880 if the ACK bit is on 2882 SYN-RECEIVED STATE 2884 If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED 2885 state and continue processing with variables below set 2886 to: 2888 SND.WND <- SEG.WND 2889 SND.WL1 <- SEG.SEQ 2890 SND.WL2 <- SEG.ACK 2892 If the segment acknowledgment is not acceptable, 2893 form a reset segment, 2895 2897 and send it. 2899 ESTABLISHED STATE 2901 If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- 2902 SEG.ACK. Any segments on the retransmission queue 2903 which are thereby entirely acknowledged are removed. 2904 Users should receive positive acknowledgments for 2905 buffers which have been SENT and fully acknowledged 2906 (i.e., SEND buffer should be returned with "ok" 2907 response). If the ACK is a duplicate (SEG.ACK =< 2908 SND.UNA), it can be ignored. If the ACK acks 2909 something not yet sent (SEG.ACK > SND.NXT) then send 2910 an ACK, drop the segment, and return. 2912 If SND.UNA =< SEG.ACK =< SND.NXT, the send window 2913 should be updated. If (SND.WL1 < SEG.SEQ or (SND.WL1 2914 = SEG.SEQ and SND.WL2 =< SEG.ACK)), set SND.WND <- 2915 SEG.WND, set SND.WL1 <- SEG.SEQ, and set SND.WL2 <- 2916 SEG.ACK. 2918 Note that SND.WND is an offset from SND.UNA, that 2919 SND.WL1 records the sequence number of the last 2920 segment used to update SND.WND, and that SND.WL2 2921 records the acknowledgment number of the last segment 2922 used to update SND.WND. The check here prevents using 2923 old segments to update the window. 2925 FIN-WAIT-1 STATE 2926 In addition to the processing for the ESTABLISHED 2927 state, if our FIN is now acknowledged then enter FIN- 2928 WAIT-2 and continue processing in that state. 2930 FIN-WAIT-2 STATE 2932 In addition to the processing for the ESTABLISHED 2933 state, if the retransmission queue is empty, the 2934 user's CLOSE can be acknowledged ("ok") but do not 2935 delete the TCB. 2937 CLOSE-WAIT STATE 2939 Do the same processing as for the ESTABLISHED state. 2941 CLOSING STATE 2943 In addition to the processing for the ESTABLISHED 2944 state, if the ACK acknowledges our FIN then enter the 2945 TIME-WAIT state, otherwise ignore the segment. 2947 LAST-ACK STATE 2949 The only thing that can arrive in this state is an 2950 acknowledgment of our FIN. If our FIN is now 2951 acknowledged, delete the TCB, enter the CLOSED state, 2952 and return. 2954 TIME-WAIT STATE 2956 The only thing that can arrive in this state is a 2957 retransmission of the remote FIN. Acknowledge it, and 2958 restart the 2 MSL timeout. 2960 sixth, check the URG bit, 2962 ESTABLISHED STATE 2963 FIN-WAIT-1 STATE 2964 FIN-WAIT-2 STATE 2966 If the URG bit is set, RCV.UP <- max(RCV.UP,SEG.UP), and 2967 signal the user that the remote side has urgent data if 2968 the urgent pointer (RCV.UP) is in advance of the data 2969 consumed. If the user has already been signaled (or is 2970 still in the "urgent mode") for this continuous sequence 2971 of urgent data, do not signal the user again. 2973 CLOSE-WAIT STATE 2974 CLOSING STATE 2975 LAST-ACK STATE 2976 TIME-WAIT 2978 This should not occur, since a FIN has been received from 2979 the remote side. Ignore the URG. 2981 seventh, process the segment text, 2983 ESTABLISHED STATE 2984 FIN-WAIT-1 STATE 2985 FIN-WAIT-2 STATE 2987 Once in the ESTABLISHED state, it is possible to deliver 2988 segment text to user RECEIVE buffers. Text from segments 2989 can be moved into buffers until either the buffer is full 2990 or the segment is empty. If the segment empties and 2991 carries an PUSH flag, then the user is informed, when the 2992 buffer is returned, that a PUSH has been received. 2994 When the TCP takes responsibility for delivering the data 2995 to the user it must also acknowledge the receipt of the 2996 data. 2998 Once the TCP takes responsibility for the data it 2999 advances RCV.NXT over the data accepted, and adjusts 3000 RCV.WND as appropriate to the current buffer 3001 availability. The total of RCV.NXT and RCV.WND should 3002 not be reduced. 3004 Please note the window management suggestions in section 3005 3.7. 3007 Send an acknowledgment of the form: 3009 3011 This acknowledgment should be piggybacked on a segment 3012 being transmitted if possible without incurring undue 3013 delay. 3015 CLOSE-WAIT STATE 3016 CLOSING STATE 3017 LAST-ACK STATE 3018 TIME-WAIT STATE 3020 This should not occur, since a FIN has been received from 3021 the remote side. Ignore the segment text. 3023 eighth, check the FIN bit, 3025 Do not process the FIN if the state is CLOSED, LISTEN or 3026 SYN-SENT since the SEG.SEQ cannot be validated; drop the 3027 segment and return. 3029 If the FIN bit is set, signal the user "connection closing" 3030 and return any pending RECEIVEs with same message, advance 3031 RCV.NXT over the FIN, and send an acknowledgment for the 3032 FIN. Note that FIN implies PUSH for any segment text not 3033 yet delivered to the user. 3035 SYN-RECEIVED STATE 3036 ESTABLISHED STATE 3038 Enter the CLOSE-WAIT state. 3040 FIN-WAIT-1 STATE 3042 If our FIN has been ACKed (perhaps in this segment), 3043 then enter TIME-WAIT, start the time-wait timer, turn 3044 off the other timers; otherwise enter the CLOSING 3045 state. 3047 FIN-WAIT-2 STATE 3049 Enter the TIME-WAIT state. Start the time-wait timer, 3050 turn off the other timers. 3052 CLOSE-WAIT STATE 3054 Remain in the CLOSE-WAIT state. 3056 CLOSING STATE 3058 Remain in the CLOSING state. 3060 LAST-ACK STATE 3062 Remain in the LAST-ACK state. 3064 TIME-WAIT STATE 3066 Remain in the TIME-WAIT state. Restart the 2 MSL 3067 time-wait timeout. 3069 and return. 3071 USER TIMEOUT 3073 USER TIMEOUT 3075 For any state if the user timeout expires, flush all queues, 3076 signal the user "error: connection aborted due to user timeout" 3077 in general and for any outstanding calls, delete the TCB, enter 3078 the CLOSED state and return. 3080 RETRANSMISSION TIMEOUT 3082 For any state if the retransmission timeout expires on a 3083 segment in the retransmission queue, send the segment at the 3084 front of the retransmission queue again, reinitialize the 3085 retransmission timer, and return. 3087 TIME-WAIT TIMEOUT 3089 If the time-wait timeout expires on a connection delete the 3090 TCB, enter the CLOSED state and return. 3092 3.11. Glossary 3094 1822 BBN Report 1822, "The Specification of the Interconnection of 3095 a Host and an IMP". The specification of interface between a 3096 host and the ARPANET. 3098 ACK 3099 A control bit (acknowledge) occupying no sequence space, 3100 which indicates that the acknowledgment field of this segment 3101 specifies the next sequence number the sender of this segment 3102 is expecting to receive, hence acknowledging receipt of all 3103 previous sequence numbers. 3105 ARPANET message 3106 The unit of transmission between a host and an IMP in the 3107 ARPANET. The maximum size is about 1012 octets (8096 bits). 3109 ARPANET packet 3110 A unit of transmission used internally in the ARPANET between 3111 IMPs. The maximum size is about 126 octets (1008 bits). 3113 connection 3114 A logical communication path identified by a pair of sockets. 3116 datagram 3117 A message sent in a packet switched computer communications 3118 network. 3120 Destination Address 3121 The destination address, usually the network and host 3122 identifiers. 3124 FIN 3125 A control bit (finis) occupying one sequence number, which 3126 indicates that the sender will send no more data or control 3127 occupying sequence space. 3129 fragment 3130 A portion of a logical unit of data, in particular an 3131 internet fragment is a portion of an internet datagram. 3133 FTP 3134 A file transfer protocol. 3136 header 3137 Control information at the beginning of a message, segment, 3138 fragment, packet or block of data. 3140 host 3141 A computer. In particular a source or destination of 3142 messages from the point of view of the communication network. 3144 Identification 3145 An Internet Protocol field. This identifying value assigned 3146 by the sender aids in assembling the fragments of a datagram. 3148 IMP 3149 The Interface Message Processor, the packet switch of the 3150 ARPANET. 3152 internet address 3153 A source or destination address specific to the host level. 3155 internet datagram 3156 The unit of data exchanged between an internet module and the 3157 higher level protocol together with the internet header. 3159 internet fragment 3160 A portion of the data of an internet datagram with an 3161 internet header. 3163 IP 3164 Internet Protocol. 3166 IRS 3167 The Initial Receive Sequence number. The first sequence 3168 number used by the sender on a connection. 3170 ISN 3171 The Initial Sequence Number. The first sequence number used 3172 on a connection, (either ISS or IRS). Selected in a way that 3173 is unique within a given period of time and is unpredictable 3174 to attackers. 3176 ISS 3177 The Initial Send Sequence number. The first sequence number 3178 used by the sender on a connection. 3180 leader 3181 Control information at the beginning of a message or block of 3182 data. In particular, in the ARPANET, the control information 3183 on an ARPANET message at the host-IMP interface. 3185 left sequence 3186 This is the next sequence number to be acknowledged by the 3187 data receiving TCP (or the lowest currently unacknowledged 3188 sequence number) and is sometimes referred to as the left 3189 edge of the send window. 3191 local packet 3192 The unit of transmission within a local network. 3194 module 3195 An implementation, usually in software, of a protocol or 3196 other procedure. 3198 MSL 3199 Maximum Segment Lifetime, the time a TCP segment can exist in 3200 the internetwork system. Arbitrarily defined to be 2 3201 minutes. 3203 octet 3204 An eight bit byte. 3206 Options 3207 An Option field may contain several options, and each option 3208 may be several octets in length. The options are used 3209 primarily in testing situations; for example, to carry 3210 timestamps. Both the Internet Protocol and TCP provide for 3211 options fields. 3213 packet 3214 A package of data with a header which may or may not be 3215 logically complete. More often a physical packaging than a 3216 logical packaging of data. 3218 port 3219 The portion of a socket that specifies which logical input or 3220 output channel of a process is associated with the data. 3222 process 3223 A program in execution. A source or destination of data from 3224 the point of view of the TCP or other host-to-host protocol. 3226 PUSH 3227 A control bit occupying no sequence space, indicating that 3228 this segment contains data that must be pushed through to the 3229 receiving user. 3231 RCV.NXT 3232 receive next sequence number 3234 RCV.UP 3235 receive urgent pointer 3237 RCV.WND 3238 receive window 3240 receive next sequence number 3241 This is the next sequence number the local TCP is expecting 3242 to receive. 3244 receive window 3245 This represents the sequence numbers the local (receiving) 3246 TCP is willing to receive. Thus, the local TCP considers 3247 that segments overlapping the range RCV.NXT to RCV.NXT + 3248 RCV.WND - 1 carry acceptable data or control. Segments 3249 containing sequence numbers entirely outside of this range 3250 are considered duplicates and discarded. 3252 RST 3253 A control bit (reset), occupying no sequence space, 3254 indicating that the receiver should delete the connection 3255 without further interaction. The receiver can determine, 3256 based on the sequence number and acknowledgment fields of the 3257 incoming segment, whether it should honor the reset command 3258 or ignore it. In no case does receipt of a segment 3259 containing RST give rise to a RST in response. 3261 RTP 3262 Real Time Protocol: A host-to-host protocol for communication 3263 of time critical information. 3265 SEG.ACK 3266 segment acknowledgment 3268 SEG.LEN 3269 segment length 3271 SEG.PRC 3272 segment precedence value 3274 SEG.SEQ 3275 segment sequence 3277 SEG.UP 3278 segment urgent pointer field 3280 SEG.WND 3281 segment window field 3283 segment 3284 A logical unit of data, in particular a TCP segment is the 3285 unit of data transfered between a pair of TCP modules. 3287 segment acknowledgment 3288 The sequence number in the acknowledgment field of the 3289 arriving segment. 3291 segment length 3292 The amount of sequence number space occupied by a segment, 3293 including any controls which occupy sequence space. 3295 segment sequence 3296 The number in the sequence field of the arriving segment. 3298 send sequence 3299 This is the next sequence number the local (sending) TCP will 3300 use on the connection. It is initially selected from an 3301 initial sequence number curve (ISN) and is incremented for 3302 each octet of data or sequenced control transmitted. 3304 send window 3305 This represents the sequence numbers which the remote 3306 (receiving) TCP is willing to receive. It is the value of 3307 the window field specified in segments from the remote (data 3308 receiving) TCP. The range of new sequence numbers which may 3309 be emitted by a TCP lies between SND.NXT and SND.UNA + 3310 SND.WND - 1. (Retransmissions of sequence numbers between 3311 SND.UNA and SND.NXT are expected, of course.) 3313 SND.NXT 3314 send sequence 3316 SND.UNA 3317 left sequence 3319 SND.UP 3320 send urgent pointer 3322 SND.WL1 3323 segment sequence number at last window update 3325 SND.WL2 3326 segment acknowledgment number at last window update 3328 SND.WND 3329 send window 3331 socket 3332 An address which specifically includes a port identifier, 3333 that is, the concatenation of an Internet Address with a TCP 3334 port. 3336 Source Address 3337 The source address, usually the network and host identifiers. 3339 SYN 3340 A control bit in the incoming segment, occupying one sequence 3341 number, used at the initiation of a connection, to indicate 3342 where the sequence numbering will start. 3344 TCB 3345 Transmission control block, the data structure that records 3346 the state of a connection. 3348 TCB.PRC 3349 The precedence of the connection. 3351 TCP 3352 Transmission Control Protocol: A host-to-host protocol for 3353 reliable communication in internetwork environments. 3355 TOS 3356 Type of Service, an Internet Protocol field. 3358 Type of Service 3359 An Internet Protocol field which indicates the type of 3360 service for this internet fragment. 3362 URG 3363 A control bit (urgent), occupying no sequence space, used to 3364 indicate that the receiving user should be notified to do 3365 urgent processing as long as there is data to be consumed 3366 with sequence numbers less than the value indicated in the 3367 urgent pointer. 3369 urgent pointer 3370 A control field meaningful only when the URG bit is on. This 3371 field communicates the value of the urgent pointer which 3372 indicates the data octet associated with the sending user's 3373 urgent call. 3375 4. Changes from RFC 793 3377 This document obsoletes RFC 793 as well as RFC 6093 and 6528, which 3378 updated 793. In all cases, only the normative protocol specification 3379 and requirements have been incorporated into this document, and the 3380 informational text with background and rationale has not been carried 3381 in. The informational content of those documents is still valuable 3382 in learning about and understanding TCP, and they are valid 3383 Informational references, even though their normative content has 3384 been incorporated into this document. 3386 The main body of this document was adapted from RFC 793's Section 3, 3387 titled "FUNCTIONAL SPECIFICATION", with an attempt to keep formatting 3388 and layout as close as possible. 3390 The collection of applicable RFC Errata that have been reported and 3391 either accepted or held for an update to RFC 793 were incorporated 3392 (Errata IDs: 573, 574, 700, 701, 1283, 1561, 1562, 1564, 1565, 1571, 3393 1572, 2296, 2297, 2298, 2748, 2749, 2934, 3213, 3300, 3301). Some 3394 errata were not applicable due to other changes (Errata IDs: 572, 3395 575, 1569, 3602). TODO: 3305 3397 Changes to the specification of the Urgent Pointer described in RFC 3398 1122 and 6093 were incorporated. See RFC 6093 for detailed 3399 discussion of why these changes were necessary. 3401 The more secure Initial Sequence Number generation algorithm from RFC 3402 6528 was incorporated. See RFC 6528 for discussion of the attacks 3403 that this mitigates, as well as advice on selecting PRF algorithms 3404 and managing secret key data. 3406 RFC EDITOR'S NOTE: the content below is for detailed change tracking 3407 and planning, and not to be included with the final revision of the 3408 document. 3410 This document started as draft-eddy-rfc793bis-00, that was merely a 3411 proposal and rough plan for updating RFC 793. 3413 The -01 revision of this document incorporates the content of RFC 793 3414 Section 3 titled "FUNCTIONAL SPECIFICATION". Other content from RFC 3415 793 has not been incorporated. The -01 revision of this document 3416 makes some minor formatting changes to the RFC 793 content in order 3417 to convert the content into XML2RFC format and account for left-out 3418 parts of RFC 793. For instance, figure numbering differs and some 3419 indentation is not exactly the same. 3421 The -02 revision of draft-eddy-rfc793bis incorporates errata that 3422 have been verified: 3424 Errata ID 573: Reported by Bob Braden (note: This errata basically 3425 is just a reminder that RFC 1122 updates 793. Some of the 3426 associated changes are left pending to a separate revision that 3427 incorporates 1122. Bob's mention of PUSH in 793 section 2.8 was 3428 not applicable here because that section was not part of the 3429 "functional specification". Also the 1122 text on the 3430 retransmission timeout also has been updated by subsequent RFCs, 3431 so the change here deviates from Bob's suggestion to apply the 3432 1122 text.) 3433 Errata ID 574: Reported by Yin Shuming 3434 Errata ID 700: Reported by Yin Shuming 3435 Errata ID 701: Reported by Yin Shuming 3436 Errata ID 1283: Reported by Pei-chun Cheng 3437 Errata ID 1561: Reported by Constantin Hagemeier 3438 Errata ID 1562: Reported by Constantin Hagemeier 3439 Errata ID 1564: Reported by Constantin Hagemeier 3440 Errata ID 1565: Reported by Constantin Hagemeier 3441 Errata ID 1571: Reported by Constantin Hagemeier 3442 Errata ID 1572: Reported by Constantin Hagemeier 3443 Errata ID 2296: Reported by Vishwas Manral 3444 Errata ID 2297: Reported by Vishwas Manral 3445 Errata ID 2298: Reported by Vishwas Manral 3446 Errata ID 2748: Reported by Mykyta Yevstifeyev 3447 Errata ID 2749: Reported by Mykyta Yevstifeyev 3448 Errata ID 2934: Reported by Constantin Hagemeier 3449 Errata ID 3213: Reported by EugnJun Yi 3450 Errata ID 3300: Reported by Botong Huang 3451 Errata ID 3301: Reported by Botong Huang 3452 Note: Some verified errata were not used in this update, as they 3453 relate to sections of RFC 793 elided from this document. These 3454 include Errata ID 572, 575, and 1569. 3455 Note: Errata ID 3602 was not applied in this revision as it is 3456 duplicative of the 1122 corrections. 3457 There is an errata 3305 currently reported that need to be 3458 verified, held, or rejected by the ADs; it is addressing the same 3459 issue as draft-gont-tcpm-tcp-seq-validation and was not attempted 3460 to be applied to this document. 3462 Not related to RFC 793 content, this revision also makes small tweaks 3463 to the introductory text, fixes indentation of the pseudoheader 3464 diagram, and notes that the Security Considerations should also 3465 include privacy, when this section is written. 3467 The -03 revision of draft-eddy-rfc793bis revises all discussion of 3468 the urgent pointer in order to comply with RFC 6093, 1122, and 1011. 3469 Since 1122 held requirements on the urgent pointer, the full list of 3470 requirements was brought into an appendix of this document, so that 3471 it can be updated as-needed. 3473 The -04 revision of draft-eddy-rfc793bis includes the ISN generation 3474 changes from RFC 6528. 3476 The -05 revision of draft-eddy-rfc793bis incorporates MSS 3477 requirements and definitions from RFC 879, 1122, and 6691, as well as 3478 option-handling requirements from RFC 1122. 3480 The -00 revision of draft-ietf-tcpm-rfc793bis incorporates several 3481 additional clarifications and updates to the section on segmentation, 3482 many of which are based on feedback from Joe Touch improving from the 3483 initial text on this in the previous revision. 3485 The -01 revision incorporates the change to Reserved bits due to ECN, 3486 as well as many other changes that come from RFC 1122. 3488 TODO: Incomplete list of other planned changes - these can be added 3489 to and made more specific, as the document proceeds: 3491 1. incorporate all other 1122 additions (sections on Data 3492 Communication, Retransmission Timeout, Managing the Window, 3493 Probing Zero Windows, Passive OPEN Calls, Time to Live, Event 3494 Processing, Acknowledging Queued Segments, Retransmission 3495 Timeout Calculation, When to Send an ACK Segment, When to Send a 3496 Window Update, When to Send Data, TCP Connection Failures, TCP 3497 Keep-Alives, TCP Multihoming, IP options, ICMP messages, remote 3498 address validation) 3499 2. point to major additional docs like 1323bis and 5681 3500 3. incorporate relevant parts of 3168 (ECN) - beyond just 3501 indicating the names of the 2 bits already done 3502 4. incorporate Fernando's new number-checking fixes (if past the 3503 IESG in time) 3504 5. point to 5461 (soft errors) 3505 6. mention 5961 state machine option 3506 7. mention 6161 (reducing TIME-WAIT) 3507 8. incorporate 6429 (ZWP/persist) 3508 9. look at Tony Sabatini suggestion for describing DO field 3509 10. clearly specify treatment of reserved bits (see TCPM thread on 3510 EDO draft April 25, 2014) 3511 11. look at possible mention of draft-minshall-nagle (e.g. as in 3512 Linux) 3513 12. make sure that clarifications in RFC 1011 are captured 3514 13. per TCPM discussion, discussion of checking reserved bits may 3515 need to be altered from 793 3516 14. per discussion with Joe Touch (TAPS list, 6/20/2015), the 3517 description of the API could be revisited 3518 15. there is inconsistency between use of SYN_RCVD and SYNC-RECEIVED 3519 in diagrams and text in various places 3520 16. TOS material does not take DSCP changes into account 3521 17. discuss with working group whether to include anything like 3522 section 4.2.3.12 of 1122 (on "efficiency" ... basically 3523 implementation advice), maybe similar to 2525 in handling for 3524 this document. also 4.2.3.11 on "TCP Traffic Patterns" 3526 5. IANA Considerations 3528 This memo includes no request to IANA. Existing IANA registries for 3529 TCP parameters are sufficient. 3531 TODO: check whether entries pointing to 793 and other documents 3532 obsoleted by this one should be updated to point to this one instead. 3534 6. Security and Privacy Considerations 3536 TODO 3538 See RFC 6093 [13] for discussion of security considerations related 3539 to the urgent pointer field. 3541 Editor's Note: Scott Brim mentioned that this should include a 3542 PERPASS/privacy review. 3544 7. Acknowledgements 3546 This document is largely a revision of RFC 793, which Jon Postel was 3547 the editor of. Due to his excellent work, it was able to last for 3548 three decades before we felt the need to revise it. 3550 Andre Oppermann was a contributor and helped to edit the first 3551 revision of this document. 3553 We are thankful for the assistance of the IETF TCPM working group 3554 chairs: 3556 Michael Scharf 3557 Yoshifumi Nishida 3558 Pasi Sarolahti 3560 During early discussion of this work on the TCPM mailing list, and at 3561 the IETF 88 meeting in Vancouver, helpful comments, critiques, and 3562 reviews were received from (listed alphebetically): David Borman, 3563 Yuchung Cheng, Martin Duke, Kevin Lahey, Kevin Mason, Matt Mathis, 3564 Hagen Paul Pfeifer, Anthony Sabatini, Joe Touch, Reji Varghese, Lloyd 3565 Wood, and Alex Zimmermann. 3567 This document includes content from errata that were reported by 3568 (listed chronologically): Yin Shuming, Bob Braden, Morris M. Keesan, 3569 Pei-chun Cheng, Constantin Hagemeier, Vishwas Manral, Mykyta 3570 Yevstifeyev, EungJun Yi, Botong Huang. 3572 8. References 3574 8.1. Normative References 3576 [1] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 3577 DOI 10.17487/RFC1191, November 1990, 3578 . 3580 [2] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 3581 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 3582 1996, . 3584 [3] Bradner, S., "Key words for use in RFCs to Indicate 3585 Requirement Levels", BCP 14, RFC 2119, 3586 DOI 10.17487/RFC2119, March 1997, 3587 . 3589 [4] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 3590 RFC 2675, DOI 10.17487/RFC2675, August 1999, 3591 . 3593 [5] Lahey, K., "TCP Problems with Path MTU Discovery", 3594 RFC 2923, DOI 10.17487/RFC2923, September 2000, 3595 . 3597 8.2. Informative References 3599 [6] Postel, J., "Transmission Control Protocol", STD 7, 3600 RFC 793, DOI 10.17487/RFC0793, September 1981, 3601 . 3603 [7] Nagle, J., "Congestion Control in IP/TCP Internetworks", 3604 RFC 896, DOI 10.17487/RFC0896, January 1984, 3605 . 3607 [8] Braden, R., Ed., "Requirements for Internet Hosts - 3608 Communication Layers", STD 3, RFC 1122, 3609 DOI 10.17487/RFC1122, October 1989, 3610 . 3612 [9] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 3613 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 3614 . 3616 [10] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. 3617 Carrier, "Marker PDU Aligned Framing for TCP 3618 Specification", RFC 5044, DOI 10.17487/RFC5044, October 3619 2007, . 3621 [11] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 3622 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 3623 . 3625 [12] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 3626 Header Compression (ROHC) Framework", RFC 5795, 3627 DOI 10.17487/RFC5795, March 2010, 3628 . 3630 [13] Gont, F. and A. Yourtchenko, "On the Implementation of the 3631 TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, 3632 January 2011, . 3634 [14] Gont, F. and S. Bellovin, "Defending against Sequence 3635 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 3636 2012, . 3638 [15] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 3639 RFC 6691, DOI 10.17487/RFC6691, July 2012, 3640 . 3642 [16] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 3643 Zimmermann, "A Roadmap for Transmission Control Protocol 3644 (TCP) Specification Documents", RFC 7414, 3645 DOI 10.17487/RFC7414, February 2015, 3646 . 3648 Appendix A. TCP Requirement Summary 3650 This section is adapted from RFC 1122. 3652 TODO: this needs to be seriously redone, to use 793bis section 3653 numbers instead of 1122 ones, the RFC1122 heading should be removed, 3654 and all 1122 requirements need to be reflected in 793bis text. 3656 TODO: NOTE that PMTUD+PLPMTUD is not included in this table of 3657 recommendations. 3659 | | | | |S| | 3660 | | | | |H| |F 3661 | | | | |O|M|o 3662 | | |S| |U|U|o 3663 | | |H| |L|S|t 3664 | |M|O| |D|T|n 3665 | |U|U|M| | |o 3666 | |S|L|A|N|N|t 3667 |RFC1122 |T|D|Y|O|O|t 3669 FEATURE |SECTION | | | |T|T|e 3670 -------------------------------------------------|--------|-|-|-|-|-|-- 3671 | | | | | | | 3672 Push flag | | | | | | | 3673 Aggregate or queue un-pushed data |4.2.2.2 | | |x| | | 3674 Sender collapse successive PSH flags |4.2.2.2 | |x| | | | 3675 SEND call can specify PUSH |4.2.2.2 | | |x| | | 3676 If cannot: sender buffer indefinitely |4.2.2.2 | | | | |x| 3677 If cannot: PSH last segment |4.2.2.2 |x| | | | | 3678 Notify receiving ALP of PSH |4.2.2.2 | | |x| | |1 3679 Send max size segment when possible |4.2.2.2 | |x| | | | 3680 | | | | | | | 3681 Window | | | | | | | 3682 Treat as unsigned number |4.2.2.3 |x| | | | | 3683 Handle as 32-bit number |4.2.2.3 | |x| | | | 3684 Shrink window from right |4.2.2.16| | | |x| | 3685 Robust against shrinking window |4.2.2.16|x| | | | | 3686 Receiver's window closed indefinitely |4.2.2.17| | |x| | | 3687 Sender probe zero window |4.2.2.17|x| | | | | 3688 First probe after RTO |4.2.2.17| |x| | | | 3689 Exponential backoff |4.2.2.17| |x| | | | 3690 Allow window stay zero indefinitely |4.2.2.17|x| | | | | 3691 Sender timeout OK conn with zero wind |4.2.2.17| | | | |x| 3692 | | | | | | | 3693 Urgent Data | | | | | | | 3694 Pointer indicates first non-urgent octet |4.2.2.4 |x| | | | | 3695 Arbitrary length urgent data sequence |4.2.2.4 |x| | | | | 3696 Inform ALP asynchronously of urgent data |4.2.2.4 |x| | | | |1 3697 ALP can learn if/how much urgent data Q'd |4.2.2.4 |x| | | | |1 3698 | | | | | | | 3699 TCP Options | | | | | | | 3700 Receive TCP option in any segment |4.2.2.5 |x| | | | | 3701 Ignore unsupported options |4.2.2.5 |x| | | | | 3702 Cope with illegal option length |4.2.2.5 |x| | | | | 3703 Implement sending & receiving MSS option |4.2.2.6 |x| | | | | 3704 IPv4 Send MSS option unless 536 |4.2.2.6 | |x| | | | 3705 IPv6 Send MSS option unless 1220 | N/A | |x| | | | 3706 Send MSS option always |4.2.2.6 | | |x| | | 3707 IPv4 Send-MSS default is 536 |4.2.2.6 |x| | | | | 3708 IPv6 Send-MSS default is 1220 | N/A |x| | | | | 3709 Calculate effective send seg size |4.2.2.6 |x| | | | | 3710 MSS accounts for varying MTU | N/A | |x| | | | 3711 | | | | | | | 3712 TCP Checksums | | | | | | | 3713 Sender compute checksum |4.2.2.7 |x| | | | | 3714 Receiver check checksum |4.2.2.7 |x| | | | | 3715 | | | | | | | 3716 ISN Selection | | | | | | | 3717 Include a clock-driven ISN generator component |4.2.2.9 |x| | | | | 3718 Secure ISN generator with a PRF component | N/A | |x| | | | 3719 | | | | | | | 3720 Opening Connections | | | | | | | 3721 Support simultaneous open attempts |4.2.2.10|x| | | | | 3722 SYN-RCVD remembers last state |4.2.2.11|x| | | | | 3723 Passive Open call interfere with others |4.2.2.18| | | | |x| 3724 Function: simultan. LISTENs for same port |4.2.2.18|x| | | | | 3725 Ask IP for src address for SYN if necc. |4.2.3.7 |x| | | | | 3726 Otherwise, use local addr of conn. |4.2.3.7 |x| | | | | 3727 OPEN to broadcast/multicast IP Address |4.2.3.14| | | | |x| 3728 Silently discard seg to bcast/mcast addr |4.2.3.14|x| | | | | 3729 | | | | | | | 3730 Closing Connections | | | | | | | 3731 RST can contain data |4.2.2.12| |x| | | | 3732 Inform application of aborted conn |4.2.2.13|x| | | | | 3733 Half-duplex close connections |4.2.2.13| | |x| | | 3734 Send RST to indicate data lost |4.2.2.13| |x| | | | 3735 In TIME-WAIT state for 2MSL seconds |4.2.2.13|x| | | | | 3736 Accept SYN from TIME-WAIT state |4.2.2.13| | |x| | | 3737 | | | | | | | 3738 Retransmissions | | | | | | | 3739 Jacobson Slow Start algorithm |4.2.2.15|x| | | | | 3740 Jacobson Congestion-Avoidance algorithm |4.2.2.15|x| | | | | 3741 Retransmit with same IP ident |4.2.2.15| | |x| | | 3742 Karn's algorithm |4.2.3.1 |x| | | | | 3743 Jacobson's RTO estimation alg. |4.2.3.1 |x| | | | | 3744 Exponential backoff |4.2.3.1 |x| | | | | 3745 SYN RTO calc same as data |4.2.3.1 | |x| | | | 3746 Recommended initial values and bounds |4.2.3.1 | |x| | | | 3747 | | | | | | | 3748 Generating ACK's: | | | | | | | 3749 Queue out-of-order segments |4.2.2.20| |x| | | | 3750 Process all Q'd before send ACK |4.2.2.20|x| | | | | 3751 Send ACK for out-of-order segment |4.2.2.21| | |x| | | 3752 Delayed ACK's |4.2.3.2 | |x| | | | 3753 Delay < 0.5 seconds |4.2.3.2 |x| | | | | 3754 Every 2nd full-sized segment ACK'd |4.2.3.2 |x| | | | | 3755 Receiver SWS-Avoidance Algorithm |4.2.3.3 |x| | | | | 3756 | | | | | | | 3757 Sending data | | | | | | | 3758 Configurable TTL |4.2.2.19|x| | | | | 3759 Sender SWS-Avoidance Algorithm |4.2.3.4 |x| | | | | 3760 Nagle algorithm |4.2.3.4 | |x| | | | 3761 Application can disable Nagle algorithm |4.2.3.4 |x| | | | | 3762 | | | | | | | 3763 Connection Failures: | | | | | | | 3764 Negative advice to IP on R1 retxs |4.2.3.5 |x| | | | | 3765 Close connection on R2 retxs |4.2.3.5 |x| | | | | 3766 ALP can set R2 |4.2.3.5 |x| | | | |1 3767 Inform ALP of R1<=retxs inform ALP |4.2.3.9 | |x| | | | 3792 Dest. Unreach (0,1,5) => abort conn |4.2.3.9 | | | | |x| 3793 Dest. Unreach (2-4) => abort conn |4.2.3.9 | |x| | | | 3794 Source Quench => slow start |4.2.3.9 | |x| | | | 3795 Time Exceeded => tell ALP, don't abort |4.2.3.9 | |x| | | | 3796 Param Problem => tell ALP, don't abort |4.2.3.9 | |x| | | | 3797 | | | | | | | 3798 Address Validation | | | | | | | 3799 Reject OPEN call to invalid IP address |4.2.3.10|x| | | | | 3800 Reject SYN from invalid IP address |4.2.3.10|x| | | | | 3801 Silently discard SYN to bcast/mcast addr |4.2.3.10|x| | | | | 3802 | | | | | | | 3803 TCP/ALP Interface Services | | | | | | | 3804 Error Report mechanism |4.2.4.1 |x| | | | | 3805 ALP can disable Error Report Routine |4.2.4.1 | |x| | | | 3806 ALP can specify TOS for sending |4.2.4.2 |x| | | | | 3807 Passed unchanged to IP |4.2.4.2 | |x| | | | 3808 ALP can change TOS during connection |4.2.4.2 | |x| | | | 3809 Pass received TOS up to ALP |4.2.4.2 | | |x| | | 3810 FLUSH call |4.2.4.3 | | |x| | | 3811 Optional local IP addr parm. in OPEN |4.2.4.4 |x| | | | | 3812 -------------------------------------------------|--------|-|-|-|-|-|-- 3813 FOOTNOTES: (1) "ALP" means Application-Layer program. 3815 Author's Address 3817 Wesley M. Eddy (editor) 3818 MTI Systems 3819 US 3821 Email: wes@mti-systems.com