| 4-bit | Nibble |
| 8-bit | Byte / Octet |
| 32-bit | Word |
Header Length or Data Offset (4 bits) specifies the number of 32-bit words in the TCP header, which indirectly indicates where the application data begins.
Unused or Reserved (6 bits) bits are reserved for future use. All must be 0s.
Flags or Control Bits (6 bits):
| URG | Indicates that the Urgent Data Pointer field is significant – data is sent out-of-band. |
| ACK | Indicates that the Acknowledgment Number field is significant. The receiver will send an ACK that equals to the sender’s sequence number plus the length (amount of data), which is also the sequence number of the next octet the receiver expects to receive. |
| PSH | The Push function forces data delivery without waiting for buffers to fill. The data will also be delivered to the user-level application on the receiving end without buffering. |
| RST | Reset – instantaneous abort a connection in both directions – an abnormal session close. |
| SYN | Synchronize the initial sequence numbers during the session establishment process. |
| FIN | Used by a graceful session close which shows that the sender has no more data to send. |
Whenever a receiving TCP sees the PSH flag, it will pass the data to the receiving process without waiting for more data – the receiving buffer that contains data associated with a PSH flag will be passed to application for processing even if the buffer is not fully filled.
Checksum (16 bits) is the 16-bit one’s complement of the one’s complement sum of the header, options, and application data. This field is filled with 0s when computing the checksum.
Note: The Header Checksum field in the IPv4 header is a checksum that is calculated based on all the fields in the IPv4 header only; hence only the IPv4 header is being checked for errors. The Header Checksum field is filled with 0s when computing the checksum.
Urgent Data Pointer (16 bits) indicates a positive offset from the current sequence number in the segment. It points to the sequence number of the octet following the urgent data (the end of the urgent data). This field is only being interpreted when the URG control bit in a segment is set. TCP must inform the application layer how much urgent data remains to be read from the connection whenever it receives a segment with an urgent data pointer.
Options (variable) may exist at the end of the TCP header. Their lengths are multiple of 8 bits. The TCP checksum covers all the TCP options.
Below lists some common TCP options:
Kind (8-bit) | Length (8-bit) | Description |
| 0 | - | EOL – End of Option List. Indicates the end of the option list. Used at the end of all options, not the end of each option. |
| 1 | - | NOP – No Operation. May be used between options to align the beginning of a subsequent option to a word boundary. |
| 2 | 4 | MSS – Maximum Segment Size. Indicates the maximum receive segment size at the TCP that sent out this segment. This option must only be sent in the initial connection request – connection request segments with SYN control bit set. Any segment size is allowed if this option is not used. |
| 4 | 2 | SACK permitted. The Selective Acknowledgment (SACK) extension uses 2 forms of TCP options: an enabling option – SACK permitted, that may be sent in a SYN segment to indicate the use of SACK option in an established connection; and the SACK option, which may be sent over an established connection after the SACK permitted is granted operation. |
| 5 | Variable | SACK options. They are used to convey extended acknowledgment information over an established connection. It is normally sent by a receiver to inform the sender about the non-contiguous blocks of received data, which mostly caused by the lost of a TCP segment. The receiver will wait for the retransmissions of the missing block of data to fill in the gap. A TCP client includes the SACK options along with the ACK segment to the TCP server whenever there is queued and unacknowledged data. SACK optimizes TCP retransmissions with selective retransmission, which skips the retransmission of selectively acknowledged segments. The SACK option can be sent only when the TCP client has received the SACK permitted option in the SYN segment from the TCP server, which indicates that the server supports SACK. |
The SACK option fields:
| Left Edge | The first sequence number of this queued and unacknowledged data block. |
| Right Edge | The last sequence number of this queued and unacknowledged data block. |
TCP Options
Padding (variable) which is comprised of 0s is used to ensure the TCP header is 32-bit aligned.
The Type of Service (TOS) field in the IP header was intended to use for TOS routing, in which a router would have separate routing tables for different TOS values. When forwarding a packet, the router would first choose a routing table based on the packet’s TOS, followed by normal routing table lookup. TOS routing has rarely been implemented in the Internet. Only 2 routing protocols – OSPF and IS-IS have ever supported the calculation of separate paths based on TOS.
The first 3 bits in the TOS field in the IP header were being used for IP Precedence, in which values from 0 – 7 can be used to specify the transmission priority of packets at each router hop. IP Precedence does not affect the path of a packet as with TOS. IP Precedence is being phased out in favor of DSCP, but is supported by many applications and routers.
Differentiated Services Code Point (DSCP) is a modification of the TOS field. 6 bits of the field are being reallocated for use as the DSCP field. DSCP is not compatible with IP Precedence.
An application can modify the handling of IP packets by extending the IP header with IP options. IP options are rarely used for regular IP packets, as most routers are heavily optimized for forwarding IP packets without IP options. The use of IP options introduces a potential DoS vulnerability against routers due to the additional processing workload of packets with IP options.
Most IP options (eg: the record-route and timestamp options) are used for statistics collection and do not affect the forwarding path of packets. However, the strict-source route and loose-source route options can be utilized by the originator of a packet to control the forwarding path the packet.
IP source routing is often considered as a security hole, as even with security is being provided through address filtering, the final destination of a packet might buried in the IP options field. As a result, most routers are configured to discard packets containing source routing options with the no ip source-route global configuration command.
No comments:
Post a Comment