idnits 2.17.1 draft-mcquistin-augmented-tcp-example-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 both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 150: '... The window size MUST be treated as an...' RFC 2119 keyword, line 152: '...(MUST-1). It is RECOMMENDED that impl...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 912 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Options' is mentioned on line 97, but not defined == Missing Reference: 'Blocks' is mentioned on line 294, but not defined == Outdated reference: A later version (-13) exists of draft-mcquistin-augmented-ascii-diagrams-09 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. McQuistin 3 Internet-Draft V. Band 4 Intended status: Experimental D. Jacob 5 Expires: 28 April 2022 C. S. Perkins 6 University of Glasgow 7 25 October 2021 9 Describing TCP with Augmented Packet Header Diagrams 10 draft-mcquistin-augmented-tcp-example-02 12 Abstract 14 This document describes TCP, and a number of its extensions, using 15 Augmented Packet Header Diagrams. This document is an example of the 16 Augmented Packet Header Diagram language: it is not intended as a 17 contribution to any ongoing or future work on maintaining or 18 extending TCP. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 28 April 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. TCP Header . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. TCP Options . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Comparison with draft-ietf-tcpm-rfc793bis . . . . . . . . . . 8 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 60 8. Informative References . . . . . . . . . . . . . . . . . . . 8 61 Appendix A. Source code repository . . . . . . . . . . . . . . . 9 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 This document uses Augmented Packet Header Diagrams 67 [AUGMENTED-DIAGRAMS] to describe TCP [RFC793], and is intended to 68 further discussion about the design and implementation of the 69 Augmented Packet Header Diagram language and tooling. Given this 70 purpose, this document is not intended as a contribution to any 71 ongoing or future work on maintaining or extending TCP. Further, 72 this document does not necessarily reflect TCP, and its extensions, 73 as presently standardised. 75 2. TCP Header 77 This document describes the TCP protocol. The TCP protocol uses TCP 78 Headers. 80 A TCP Header is formatted as follows: 82 0 1 2 3 83 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 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | Source Port | Destination Port | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 | Sequence Number | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | Acknowledgment Number | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | Data | |C|E|U|A|P|R|S|F| | 92 | Offset| Rsrvd |W|C|R|C|S|S|Y|I| Window Size | 93 | | |R|E|G|K|H|T|N|N| | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Checksum | Urgent Pointer | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | [Options] | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | : 100 : Payload : 101 : | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 where: 106 Source Port: 16 bits. The source port number. 108 Destination Port: 16 bits. The destination port number. 110 Sequence Number: 32 bits. The sequence number of the first data 111 octet in this segment (except when the SYN flag is set). If SYN 112 is set the sequence number is the initial sequence number (ISN) 113 and the first data octet is ISN+1. 115 Acknowledgment Number: 32 bits. If the ACK control bit is set, this 116 field contains the value of the next sequence number the sender of 117 the segment is expecting to receive. Once a connection is 118 established, this is always sent. 120 Data Offset (DOffset): 4 bits; DOffset >= 5. The number of 32 bit 121 words in the TCP Header. This indicates where the data begins. 122 The TCP header (even one including options) is an integral number 123 of 32 bits long. 125 Reserved (Rsrvd): 4 bits; Rsrvd == 0. A set of control bits reserved 126 for future use. Must be zero in generated segments and must be 127 ignored in received segments, if corresponding future features are 128 unimplemented by the sending or receiving host. 130 CWR: 1 bit. Congestion Window Reduced 132 ECE: 1 bit. ECN-Echo 134 URG: 1 bit. Urgent Pointer field significant 136 ACK: 1 bit. Acknowledgment field significant. 138 PSH: 1 bit. Push Function (see the Send Call description) 140 RST: 1 bit. Reset the connection 142 SYN: 1 bit. Synchronize sequence numbers 144 FIN: 1 bit; (FIN == 0) || (SYN == 0). No more data from sender. 146 Window Size: 16 bits. The number of data octets beginning with the 147 one indicated in the acknowledgment field that the sender of this 148 segment is willing to accept. 150 The window size MUST be treated as an unsigned number, or else 151 large window sizes will appear like negative windows and TCP will 152 not work (MUST-1). It is RECOMMENDED that implementations will 153 reserve 32-bit fields for the send and receive window sizes in the 154 connection record and do all window computations with 32 bits 155 (REC- 1). 157 Checksum: 16 bits. The checksum field is the 16 bit one's complement 158 of the one's complement sum of all 16 bit words in the header and 159 text. The checksum computation needs to ensure the 16-bit 160 alignment of the data being summed. If a segment contains an odd 161 number of header and text octets, alignment can be achieved by 162 padding the last octet with zeros on its right to form a 16 bit 163 word for checksum purposes. The pad is not transmitted as part of 164 the segment. While computing the checksum, the checksum field 165 itself is replaced with zeros. 167 Urgent Pointer: 16 bits. This field communicates the current value 168 of the urgent pointer as a positive offset from the sequence 169 number in this segment. The urgent pointer points to the sequence 170 number of the octet following the urgent data. This field is only 171 be interpreted in segments with the URG control bit set. 173 Options: [TCP Option]; size(Options) == (DOffset-5)*32; present 174 only when DOffset > 5. Options may occupy space at the end of the 175 TCP header and are a multiple of 8 bits in length. All options 176 are included in the checksum. 178 Payload. Payload. 180 3. TCP Options 182 A TCP Option is one of: a EOL Option, a NOOP Option, a Maximum 183 Segment Size Option, a Window Scale Factor Option, a Timestamp 184 Option, a SACK Permitted Option, or a SACK Range Option. 186 An EOL Option is formatted as follows: 188 0 189 0 1 2 3 4 5 6 7 190 +-+-+-+-+-+-+-+-+ 191 | 0 | 192 +-+-+-+-+-+-+-+-+ 194 where: 196 Option Kind (Kind): 1 byte; Kind == 0. This option code indicates 197 the end of the option list. 199 A NOOP Option is formatted as follows: 201 0 202 0 1 2 3 4 5 6 7 203 +-+-+-+-+-+-+-+-+ 204 | 1 | 205 +-+-+-+-+-+-+-+-+ 207 where: 209 Option Kind (Kind): 1 byte; Kind == 1. This option code can be used 210 between options, for example, to align the beginning of a 211 subsequent option on a word boundary. 213 A Maximum Segment Size Option is formatted as follows: 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | 2 | Length | Maximum Segment Size (MSS) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 where: 223 Option Kind (Kind): 1 byte; Kind == 2. If this option is present, 224 then it communicates the maximum receive segment size at the TCP 225 endpoint that sends this segment. 227 Option Length (Length): 1 byte; Length == 4. Option length. 229 Maximum Segment Size (MSS): 2 bytes. The maximum segment size 230 allowed. 232 A Window Scale Factor Option is formatted as follows: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | 3 | Length | Window Scale | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 where: 242 Option Kind (Kind): 1 byte; Kind == 3. If present, this option 243 carries the window scale factor. 245 Option Length (Length): 1 byte; Length == 3. Option length. 247 Window Scale: 1 byte. Window scale factor. 249 A Timestamp Option is formatted as follows: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | 8 | Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Timestamp value (TSval) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Timestamp echo reply (TSecr) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 where: 263 Option Kind (Kind): 1 byte; Kind == 8. If present, this option 264 carries a timestamp and an echoed timestamp. 266 Option Length (Length): 1 byte; Length == 10. Option length. 268 Timestamp value (TSval): 4 bytes. TSval. 270 Timestamp echo reply (TSecr): 4 bytes. TSecr. 272 A SACK Permitted Option is formatted as follows: 274 0 1 275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | 4 | Length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 where: 282 Option Kind (Kind): 1 byte; Kind == 4. If present, this option 283 indicates that SACK is permitted. 285 Option Length (Length): 1 byte; Length == 2. Option length. 287 A SACK Range Option is formatted as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | 5 | Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | [Blocks] | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 where: 299 Option Kind (Kind): 1 byte; Kind == 5. If present, this option 300 contains one or more SACK blocks. 302 Option Length (Length): 1 byte. Option length. 304 Blocks: (Length-2)/8 SACK Blocks. SACK blocks. 306 A SACK Block is formatted as follows: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Left Edge | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Right Edge | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 where: 318 Left Edge: 4 bytes. This is the first sequence number of this block. 320 Right Edge: 4 bytes. This is the sequence number immediately 321 following the last sequence number of this block. 323 4. Comparison with draft-ietf-tcpm-rfc793bis 325 The Augmented Packet Header Diagram format used in this example has 326 also been adopted within [draft-ietf-tcpm-rfc793bis]. This example 327 goes beyond [draft-ietf-tcpm-rfc793bis], and includes a number of TCP 328 options that are not defined as part of that document, including the 329 Window Scale Factor, Timestamp, SACK permitted, and SACK block 330 options. In addition, the definition of the TCP header (Section 2) 331 in this document includes a number of field constraints that are not 332 specified in [draft-ietf-tcpm-rfc793bis]. 334 The purpose of this document is to give an example use of the 335 Augmented Packet Header Diagrams, and not to contribute to ongoing or 336 future TCP standardisation efforts. We include additional 337 constraints and TCP options to demonstrate the ease with which these 338 can be expressed in our format, and that these are then supported by 339 the generated parser code. 341 5. IANA Considerations 343 This document contains no actions for IANA. 345 6. Security Considerations 347 The security implications of the Augmented Packet Header Diagrams 348 format are considered in [AUGMENTED-DIAGRAMS]. 350 7. Acknowledgements 352 This work has received funding from the UK Engineering and Physical 353 Sciences Research Council under grant EP/R04144X/1. 355 8. Informative References 357 [AUGMENTED-DIAGRAMS] 358 McQuistin, S., Band, V., Jacob, D., and C. S. Perkins, 359 "Describing Protocol Data Units with Augmented Packet 360 Header Diagrams", Work in Progress, Internet-Draft, draft- 361 mcquistin-augmented-ascii-diagrams-09, 25 October 2021, 362 . 365 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, 366 September 1981, . 368 [draft-ietf-tcpm-rfc793bis] 369 Eddy, W., "Transmission Control Protocol (TCP) 370 Specification", Work in Progress, Internet-Draft, draft- 371 ietf-tcpm-rfc793bis-25, 7 September 2021, 372 . 375 Appendix A. Source code repository 377 The source code for tooling that can be used to parse this document, 378 and generate parser code for the protocol it describes, is available 379 from https://github.com/glasgow-ipl/ips-protodesc-code. 381 Authors' Addresses 383 Stephen McQuistin 384 University of Glasgow 385 School of Computing Science 386 Glasgow 387 G12 8QQ 388 United Kingdom 390 Email: sm@smcquistin.uk 392 Vivian Band 393 University of Glasgow 394 School of Computing Science 395 Glasgow 396 G12 8QQ 397 United Kingdom 399 Email: vivianband0@gmail.com 401 Dejice Jacob 402 University of Glasgow 403 School of Computing Science 404 Glasgow 405 G12 8QQ 406 United Kingdom 408 Email: d.jacob.1@research.gla.ac.uk 409 Colin Perkins 410 University of Glasgow 411 School of Computing Science 412 Glasgow 413 G12 8QQ 414 United Kingdom 416 Email: csp@csperkins.org