| < draft-ietf-tcpm-rfc793bis-27.txt | draft-ietf-tcpm-rfc793bis-28.txt > | |||
|---|---|---|---|---|
| Internet Engineering Task Force W. Eddy, Ed. | Internet Engineering Task Force W. Eddy, Ed. | |||
| Internet-Draft MTI Systems | Internet-Draft MTI Systems | |||
| Obsoletes: 793, 879, 2873, 6093, 6429, 6528, 22 February 2022 | Obsoletes: 793, 879, 2873, 6093, 6429, 6528, 7 March 2022 | |||
| 6691 (if approved) | 6691 (if approved) | |||
| Updates: 5961, 1011, 1122 (if approved) | Updates: 5961, 1011, 1122 (if approved) | |||
| Intended status: Standards Track | Intended status: Standards Track | |||
| Expires: 26 August 2022 | Expires: 8 September 2022 | |||
| Transmission Control Protocol (TCP) Specification | Transmission Control Protocol (TCP) Specification | |||
| draft-ietf-tcpm-rfc793bis-27 | draft-ietf-tcpm-rfc793bis-28 | |||
| Abstract | Abstract | |||
| This document specifies the Transmission Control Protocol (TCP). TCP | This document specifies the Transmission Control Protocol (TCP). TCP | |||
| is an important transport layer protocol in the Internet protocol | is an important transport layer protocol in the Internet protocol | |||
| stack, and has continuously evolved over decades of use and growth of | stack, and has continuously evolved over decades of use and growth of | |||
| the Internet. Over this time, a number of changes have been made to | the Internet. Over this time, a number of changes have been made to | |||
| TCP as it was specified in RFC 793, though these have only been | TCP as it was specified in RFC 793, though these have only been | |||
| documented in a piecemeal fashion. This document collects and brings | documented in a piecemeal fashion. This document collects and brings | |||
| those changes together with the protocol specification from RFC 793. | those changes together with the protocol specification from RFC 793. | |||
| skipping to change at page 1, line 49 ¶ | skipping to change at page 1, line 49 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 26 August 2022. | This Internet-Draft will expire on 8 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 49, line 44 ¶ | skipping to change at page 49, line 44 ¶ | |||
| (where RMSS is the MSS specified by the TCP endpoint receiving the | (where RMSS is the MSS specified by the TCP endpoint receiving the | |||
| segments to be acknowledged, or the default value if not specified) | segments to be acknowledged, or the default value if not specified) | |||
| (SHLD-19). Excessive delays on ACKs can disturb the round-trip | (SHLD-19). Excessive delays on ACKs can disturb the round-trip | |||
| timing and packet "clocking" algorithms. More complete discussion of | timing and packet "clocking" algorithms. More complete discussion of | |||
| delayed ACK behavior is in Section 4.2 of RFC 5681 [8], including | delayed ACK behavior is in Section 4.2 of RFC 5681 [8], including | |||
| recommendations to immediately acknowledge out-of-order segments, | recommendations to immediately acknowledge out-of-order segments, | |||
| segments above a gap in sequence space, or segments that fill all or | segments above a gap in sequence space, or segments that fill all or | |||
| part of a gap, in order to accelerate loss recovery. | part of a gap, in order to accelerate loss recovery. | |||
| Note that there are several current practices that further lead to a | Note that there are several current practices that further lead to a | |||
| reduced number of ACKs, including generic receive offload (GRO), ACK | reduced number of ACKs, including generic receive offload (GRO) [73], | |||
| compression, and ACK decimation [29]. | ACK compression, and ACK decimation [29]. | |||
| 3.9. Interfaces | 3.9. Interfaces | |||
| There are of course two interfaces of concern: the user/TCP interface | There are of course two interfaces of concern: the user/TCP interface | |||
| and the TCP/lower level interface. We have a fairly elaborate model | and the TCP/lower level interface. We have a fairly elaborate model | |||
| of the user/TCP interface, but the interface to the lower level | of the user/TCP interface, but the interface to the lower level | |||
| protocol module is left unspecified here, since it will be specified | protocol module is left unspecified here, since it will be specified | |||
| in detail by the specification of the lower level protocol. For the | in detail by the specification of the lower level protocol. For the | |||
| case that the lower level is IP we note some of the parameter values | case that the lower level is IP we note some of the parameter values | |||
| that TCP implementations might use. | that TCP implementations might use. | |||
| skipping to change at page 60, line 52 ¶ | skipping to change at page 60, line 52 ¶ | |||
| classified as either "soft" or "hard" errors that may bear different | classified as either "soft" or "hard" errors that may bear different | |||
| responses. Treatment for classes of ICMP messages is described | responses. Treatment for classes of ICMP messages is described | |||
| below: | below: | |||
| Source Quench | Source Quench | |||
| TCP implementations MUST silently discard any received ICMP Source | TCP implementations MUST silently discard any received ICMP Source | |||
| Quench messages (MUST-55). See [11] for discussion. | Quench messages (MUST-55). See [11] for discussion. | |||
| Soft Errors | Soft Errors | |||
| For IPv4 ICMP these include: Destination Unreachable -- codes 0, 1, | For IPv4 ICMP these include: Destination Unreachable -- codes 0, 1, | |||
| 5, Time Exceeded -- codes 0, 1, and Parameter Problem. | 5; Time Exceeded -- codes 0, 1; and Parameter Problem. | |||
| For ICMPv6 these include: Destination Unreachable -- codes 0 and 3, | For ICMPv6 these include: Destination Unreachable -- codes 0, 3; | |||
| Time Exceeded -- codes 0, 1, and Parameter Problem -- codes 0, 1, | Time Exceeded -- codes 0, 1; and Parameter Problem -- codes 0, 1, | |||
| 2. | 2. | |||
| Since these Unreachable messages indicate soft error conditions, | Since these Unreachable messages indicate soft error conditions, | |||
| TCP implementations MUST NOT abort the connection (MUST-56), and it | TCP implementations MUST NOT abort the connection (MUST-56), and it | |||
| SHOULD make the information available to the application (SHLD-25). | SHOULD make the information available to the application (SHLD-25). | |||
| Hard Errors | Hard Errors | |||
| For ICMP these include Destination Unreachable -- codes 2-4. | For ICMP these include Destination Unreachable -- codes 2-4. | |||
| These are hard error conditions, so TCP implementations SHOULD | These are hard error conditions, so TCP implementations SHOULD | |||
| skipping to change at page 63, line 29 ¶ | skipping to change at page 63, line 29 ¶ | |||
| CLOSED STATE (i.e., TCB does not exist) | CLOSED STATE (i.e., TCB does not exist) | |||
| - Create a new transmission control block (TCB) to hold | - Create a new transmission control block (TCB) to hold | |||
| connection state information. Fill in local socket identifier, | connection state information. Fill in local socket identifier, | |||
| remote socket, DiffServ field, security/compartment, and user | remote socket, DiffServ field, security/compartment, and user | |||
| timeout information. Note that some parts of the remote socket | timeout information. Note that some parts of the remote socket | |||
| may be unspecified in a passive OPEN and are to be filled in by | may be unspecified in a passive OPEN and are to be filled in by | |||
| the parameters of the incoming SYN segment. Verify the | the parameters of the incoming SYN segment. Verify the | |||
| security and DiffServ value requested are allowed for this | security and DiffServ value requested are allowed for this | |||
| user, if not return "error: precedence not allowed" or "error: | user, if not return "error: DiffServ value not allowed" or | |||
| security/compartment not allowed." If passive enter the LISTEN | "error: security/compartment not allowed." If passive enter | |||
| state and return. If active and the remote socket is | the LISTEN state and return. If active and the remote socket | |||
| unspecified, return "error: remote socket unspecified"; if | is unspecified, return "error: remote socket unspecified"; if | |||
| active and the remote socket is specified, issue a SYN segment. | active and the remote socket is specified, issue a SYN segment. | |||
| An initial send sequence number (ISS) is selected. A SYN | An initial send sequence number (ISS) is selected. A SYN | |||
| segment of the form <SEQ=ISS><CTL=SYN> is sent. Set SND.UNA to | segment of the form <SEQ=ISS><CTL=SYN> is sent. Set SND.UNA to | |||
| ISS, SND.NXT to ISS+1, enter SYN-SENT state, and return. | ISS, SND.NXT to ISS+1, enter SYN-SENT state, and return. | |||
| - If the caller does not have access to the local socket | - If the caller does not have access to the local socket | |||
| specified, return "error: connection illegal for this process". | specified, return "error: connection illegal for this process". | |||
| If there is no room to create a new connection, return "error: | If there is no room to create a new connection, return "error: | |||
| insufficient resources". | insufficient resources". | |||
| skipping to change at page 76, line 44 ¶ | skipping to change at page 76, line 44 ¶ | |||
| o SYN-RECEIVED STATE | o SYN-RECEIVED STATE | |||
| + If the RST bit is set | + If the RST bit is set | |||
| * If this connection was initiated with a passive OPEN | * If this connection was initiated with a passive OPEN | |||
| (i.e., came from the LISTEN state), then return this | (i.e., came from the LISTEN state), then return this | |||
| connection to LISTEN state and return. The user need | connection to LISTEN state and return. The user need | |||
| not be informed. If this connection was initiated | not be informed. If this connection was initiated | |||
| with an active OPEN (i.e., came from SYN-SENT state) | with an active OPEN (i.e., came from SYN-SENT state) | |||
| then the connection was refused, signal the user | then the connection was refused, signal the user | |||
| "connection refused". In either case, all segments on | "connection refused". In either case, the | |||
| the retransmission queue should be removed. And in | retransmission queue should be flushed. And in the | |||
| the active OPEN case, enter the CLOSED state and | active OPEN case, enter the CLOSED state and delete | |||
| delete the TCB, and return. | the TCB, and return. | |||
| o ESTABLISHED | o ESTABLISHED | |||
| FIN-WAIT-1 | FIN-WAIT-1 | |||
| FIN-WAIT-2 | FIN-WAIT-2 | |||
| CLOSE-WAIT | CLOSE-WAIT | |||
| + If the RST bit is set then, any outstanding RECEIVEs and | + If the RST bit is set then, any outstanding RECEIVEs and | |||
| SEND should receive "reset" responses. All segment | SEND should receive "reset" responses. All segment | |||
| skipping to change at page 85, line 5 ¶ | skipping to change at page 85, line 5 ¶ | |||
| Destination Address | Destination Address | |||
| The network layer address of the endpoint intended to receive | The network layer address of the endpoint intended to receive | |||
| a segment. | a segment. | |||
| FIN | FIN | |||
| A control bit (finis) occupying one sequence number, which | A control bit (finis) occupying one sequence number, which | |||
| indicates that the sender will send no more data or control | indicates that the sender will send no more data or control | |||
| occupying sequence space. | occupying sequence space. | |||
| flush | ||||
| To remove all of the contents (data or segments) from a store | ||||
| (buffer or queue). | ||||
| fragment | fragment | |||
| A portion of a logical unit of data, in particular an | A portion of a logical unit of data, in particular an | |||
| internet fragment is a portion of an internet datagram. | internet fragment is a portion of an internet datagram. | |||
| header | header | |||
| Control information at the beginning of a message, segment, | Control information at the beginning of a message, segment, | |||
| fragment, packet or block of data. | fragment, packet or block of data. | |||
| host | host | |||
| A computer. In particular a source or destination of | A computer. In particular a source or destination of | |||
| messages from the point of view of the communication network. | messages from the point of view of the communication network. | |||
| Identification | Identification | |||
| An Internet Protocol field. This identifying value assigned | An Internet Protocol field. This identifying value assigned | |||
| by the sender aids in assembling the fragments of a datagram. | by the sender aids in assembling the fragments of a datagram. | |||
| internet address | internet address | |||
| A network layer address. | A network layer address. | |||
| internet datagram | internet datagram | |||
| The unit of data exchanged between an internet module and the | A unit of data exchanged between internet hosts, together | |||
| higher level protocol together with the internet header. | with the internet header that allows the datagram to be | |||
| routed from source to destination. | ||||
| internet fragment | internet fragment | |||
| A portion of the data of an internet datagram with an | A portion of the data of an internet datagram with an | |||
| internet header. | internet header. | |||
| IP | IP | |||
| Internet Protocol. See [1] and [13]. | Internet Protocol. See [1] and [13]. | |||
| IRS | IRS | |||
| The Initial Receive Sequence number. The first sequence | The Initial Receive Sequence number. The first sequence | |||
| skipping to change at page 95, line 51 ¶ | skipping to change at page 95, line 51 ¶ | |||
| The -25 revision incorporates changes based on the GENART review from | The -25 revision incorporates changes based on the GENART review from | |||
| Francis Dupont, SECDIR review from Kyle Rose, and OPSDIR review from | Francis Dupont, SECDIR review from Kyle Rose, and OPSDIR review from | |||
| Sarah Banks. | Sarah Banks. | |||
| The -26 revision incorporates changes stemming from the IESG reviews, | The -26 revision incorporates changes stemming from the IESG reviews, | |||
| and INTDIR review from Bernie Volz. | and INTDIR review from Bernie Volz. | |||
| The -27 revision fixes a few small editorial incompatibilities that | The -27 revision fixes a few small editorial incompatibilities that | |||
| Stephen McQuistin found related to automated code generation. | Stephen McQuistin found related to automated code generation. | |||
| The -28 revision addresses some COMMENTs from Ben Kaduk's IESG | ||||
| review. | ||||
| Some other suggested changes that will not be incorporated in this | Some other suggested changes that will not be incorporated in this | |||
| 793 update unless TCPM consensus changes with regard to scope are: | 793 update unless TCPM consensus changes with regard to scope are: | |||
| 1. Tony Sabatini's suggestion for describing DO field | 1. Tony Sabatini's suggestion for describing DO field | |||
| 2. Per discussion with Joe Touch (TAPS list, 6/20/2015), the | 2. Per discussion with Joe Touch (TAPS list, 6/20/2015), the | |||
| description of the API could be revisited | description of the API could be revisited | |||
| 3. Reducing the R2 value for SYNs has been suggested as a possible | 3. Reducing the R2 value for SYNs has been suggested as a possible | |||
| topic for future consideration. | topic for future consideration. | |||
| Early in the process of updating RFC 793, Scott Brim mentioned that | Early in the process of updating RFC 793, Scott Brim mentioned that | |||
| skipping to change at page 107, line 41 ¶ | skipping to change at page 107, line 41 ¶ | |||
| 454-473, December 1978. | 454-473, December 1978. | |||
| [71] Faber, T., Touch, J., and W. Yui, "The TIME-WAIT state in | [71] Faber, T., Touch, J., and W. Yui, "The TIME-WAIT state in | |||
| TCP and Its Effect on Busy Servers", Proceedings of IEEE | TCP and Its Effect on Busy Servers", Proceedings of IEEE | |||
| INFOCOM pp. 1573-1583, March 1999. | INFOCOM pp. 1573-1583, March 1999. | |||
| [72] Postel, J., "Comments on Action Items from the January | [72] Postel, J., "Comments on Action Items from the January | |||
| Meeting", IEN 177, March 1981, | Meeting", IEN 177, March 1981, | |||
| <https://www.rfc-editor.org/ien/ien177.txt>. | <https://www.rfc-editor.org/ien/ien177.txt>. | |||
| [73] "Segmentation Offloads", Linux Networking Documentation , | ||||
| <https://www.kernel.org/doc/html/latest/networking/ | ||||
| segmentation-offloads.html>. | ||||
| Appendix A. Other Implementation Notes | Appendix A. Other Implementation Notes | |||
| This section includes additional notes and references on TCP | This section includes additional notes and references on TCP | |||
| implementation decisions that are currently not a part of the RFC | implementation decisions that are currently not a part of the RFC | |||
| series or included within the TCP standard. These items can be | series or included within the TCP standard. These items can be | |||
| considered by implementers, but there was not yet a consensus to | considered by implementers, but there was not yet a consensus to | |||
| include them in the standard. | include them in the standard. | |||
| A.1. IP Security Compartment and Precedence | A.1. IP Security Compartment and Precedence | |||
| End of changes. 13 change blocks. | ||||
| 19 lines changed or deleted | 31 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||