TCP Segment Format
Transport Layer Protocols
Two protocols: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are defined for transmitting datagrams. We will look at the details of both these protocols as well as their interaction with the upper layer.
Transmission Control Protocol (TCP)
TCP is connection-oriented in the sense that prior to transmission end points need to establish a connection first. TCP protocol data units are called segments. The sending and receiving TCP entities exchange data in the form of segments, which consist of a fixed 20-byte header followed by a variable size data field.
TCP is responsible for breaking down a stream of bytes into segments and reconnecting them at the other end, retransmitting whatever might be lost and also organizing the segments in the correct order. The segment size is restricted by the maximum transfer unit (MTU) of the underlying link layer technology (MTU is generally 1500 bytes which is the maximum payload size of the Ethernet).
The image below shows the TCP segment format.
Source Port and Destination Port fields together identify the two local end points of the particular connection. A port plus its hosts’ IP address forms a unique end point. Ports are used to communicate with the upper layer and distinguish different application sessions on the host.
The Sequence Number and Acknowledgment Number fields specify bytes in the byte stream. The sequence number is used for segment differentiation and is useful for reordering or retransmitting lost segments. The Acknowledgment number is set to the next segment expected.
Data offset or TCP header length indicates how many 4-byte words are contained in the TCP header.
The Window field indicates how many bytes can be transmitted before an acknowledgment is received.
The Checksum field is used to provide extra reliability and security to the TCP segment.
The actual user data are included after the end of the header.
Let’s have a look at how a TCP segment is captured by Ethereal network analyzer.
User Datagram Protocol (UDP)
UDP protocol consists of fewer fields compared to TCP. The reason for that is because certain data types do not require reliable delivery and extra overhead. Real-time traffic for example, needs to be transported in an efficient way without error correction and retransmission mechanisms.
UDP is considered to be a connectionless protocol. It leaves reliability to be handled by the application layer. All it cares about is fast transmission. The UDP segment format is presented in the diagram below:
Let’s see how a UDP segment is captured by Ethereal. Notice the small header size.
IP Packet Header
IP header includes many relevant information including Version Number, which, in this context, is 4. Other details are as follows:
Version: Version no. of Internet Protocol used(e.g. IPv4).
IHL: Internet Header Length; Length of entire IP header.
ECN: Explicit Congestion Notification;
It carries information about the congestion seen in the route.
Total Length: Length of entire IP Packet
(including IP header and IP Payload).
Identification: If IP packet is fragmented during the
transmission, all the fragments contain
same identification number. To identify original
IP packet they belong to.
Flags: As required by the network resources,
if IP Packet is too large to handle, these ‘flags’
tells if they can be fragmented or not.
In this 3-bit flag, the MSB is always set to ‘0’.
Fragment Offset: This offset tells the exact position
of the fragment in the original IP Packet.
Time to Live: To avoid looping in the network,
every packet is sent with some TTL value set,
which tells the network how many routers (hops)
this packet can cross.
At each hop, its value is decremented by one and
when the value reaches zero, the packet is discarded.
Protocol: Tells the Network layer at the destination host,
to which Protocol this packet belongs to,
i.e. the next level Protocol.
For example protocol number of ICMP is 1, TCP is 6 and UDP is 17.
Header Checksum: This field is used to keep checksum value
of entire header which is then used to check if
the packet is received error-free.
Source Address: 32-bit address of the Sender(or source)
of the packet.
Destination Address: 32-bit address of the Receiver
(or destination) of the packet.
Now that we've examined what is contained in a Layer 3 (IP) header, let's move on to the Layer 4 header. A Layer 4 header occurs at the very beginning of the IP data field and can be either a TCP header or a UDP header. Let's start with the fields that will be found in a Layer 4 TCP header:
IP protocol is one of the main protocols in the TCP/IP stack.
IP Layer in TCP/IP Suite
As can be seen from the image above, the IP protocol sits at the layer-2 of TCP/IP protocol suite ie the Internet layer. Another point worth noting here is how the data is packed in TCP/IP suite. If we analyze the figure above, we see :
- The application layer sends the data (to be transferred to remote destination ) to the transport layer.
- The transport layer puts its header in the beginning and sends this complete packet (TCP-header + app-data) to the IP layer.
- On the same lines, The IP layer puts its header in front of the data received from TCP (Note that data received from TCP = TCP-header + app-data).
- So now the structure of IP datagram becomes IP-header + TCP-header + app-data.
- This IP datagram is passed to the ethernet layer which on the same lines adds its own header to IP datagram and then the whole packet is transmitted over network.
On the destination host, the reverse process happens. This means that each layer reads its own header in the packet and then strips the header so that finally application receives the app-data.
IP Header
The Internet Protocol (IP), defined by IETF RFC791, is the routing layer datagram service of the TCP/IP suite. use IP to route frames from host to host. The IP frame header contains routing information and control information associated with datagram delivery.
The IP header structure is as follows:
Version(4 bits)
Version field indicates the format of the Internet header.
Version field indicates the format of the Internet header.
This is the first field in the protocol header. This field occupies 4 bits. This signifies the current IP protocol version being used. Most common version of IP protocol being used is version 4.written in binary. For example if you are using IPv4, the bits will be set to 0100; if you are using IPv6, the bits will be set to 0110.
IHL or header length(4 bits)
IHL or header length(4 bits)
Internet header length is the length of the Internet header in 32-bit words. Points to the beginning of the data. The minimum value for a correct header is 5. Usually when no options are present then the value of this field is 5. Here 5 means five 32 bit words ie 5 *4 = 20 bytes.
This 4-bit field indicates how long the IP packet header is; this value is used to distinguish which part of the IP packet is the header, and which part is the actual data.
Type of service(8 bits)
The first three bits of this field are known as precedence bits and are ignored as of today. The next 4 bits represent type of service and the last bit is left unused.
This field is 8 bits long; the first 3 bits are called precedence bits and the last 5 bits represent the type of service flags. These flags were originally created to prioritize which packets should be delivered and which packets could be dropped if a router became congested. Since then, other protocols have been invented to prioritize traffic and most routers ignore these flags even if they have been set.
Bits 0-2: Precedence
111 Network control.
110 Internetwork control.
101 CRITIC/ECP.
100 Flash override.
011 Flash.
010 Immediate.
001 Priority.
000 Routine.
Bit 3: Delay
0 Normal delay.
1 Low delay.
Bit 4: Throughput
0 Normal throughput.
1 High throughput.
Bit 5: Reliability
0 Normal reliability.
1 High reliability.
Bits 6-7: Reserved for future use.
111 Network control.
110 Internetwork control.
101 CRITIC/ECP.
100 Flash override.
011 Flash.
010 Immediate.
001 Priority.
000 Routine.
Bit 3: Delay
0 Normal delay.
1 Low delay.
Bit 4: Throughput
0 Normal throughput.
1 High throughput.
Bit 5: Reliability
0 Normal reliability.
1 High reliability.
Bits 6-7: Reserved for future use.
Total length(16 bits)
Length of the datagram measured in bytes, including the Internet header and data.
Length of the datagram measured in bytes, including the Internet header and data.
This 16-bit field represents the total length of the IP packet, meaning both the data and the header. The minimum size is 21 bytes (default header size plus one byte of data). Since this field is 16 bits long, the maximum packet size is 2 to the power of 16 minus one, or 65,535 bytes. (The minus one represents the illegal length value of 0.)
Identification(16 bits)
Identifying value assigned by the sender to aid in assembling the fragments of a datagram.
Identifying value assigned by the sender to aid in assembling the fragments of a datagram.
This field is used for uniquely identifying the IP datagrams. This value is incremented every-time an IP datagram is sent from source to the destination.
Every IP packet is given an identification number when it is created; that number is contained within this 16-bit field. It is possible for an IP packet to be separated into smaller "fragments" before it reaches its final destination; each fragment still belongs to the original IP packet, so each fragment will have the same identification number.
Flags(3 bits)
This field comprises of three bits. While the first bit is kept reserved as of now, the next two bits have their own importance. The second bit represents the ‘Don’t Fragment’ bit. When this bit is set then IP datagram is never fragmented, rather its thrown away if a requirement for fragment arises. The third bit represents the ‘More Fragment’ bit.
This field contains three flags as follows:
reserved flag: must always be 0
reserved flag: must always be 0
don't fragment flag: if set to 0, this flag is off, meaning you can fragment the IP packet; if set to 1, this flag is on, meaning you don't fragment this IP packet
more fragments flag: if set to 0, there are no more fragments; if set to 1, there are more fragments of this IP packet yet to arrive.
Control flags:
Bit 0 is reserved and must be zero
Bit 1: Don’t fragment bit:
0 May fragment.
1 Don’t fragment.
Bit 2: More fragments bit:
0 Last fragment.
1 More fragments.
Bit 0 is reserved and must be zero
Bit 1: Don’t fragment bit:
0 May fragment.
1 Don’t fragment.
Bit 2: More fragments bit:
0 Last fragment.
1 More fragments.
Fragment offset(13 bits): In case of fragmented IP data grams, this field contains the offset( in terms of 8 bytes units) from the start of IP datagram. So again, this field is used in reassembly of fragmented IP datagrams .
Indicates where this fragment belongs in the datagram. The fragment offset is measured in units of 8 bytes (64 bits). The first fragment has offset zero.
Time to live(8 bits)
Indicates the maximum time the datagram is allowed to remain in the Internet system. If this field contains the value zero, the datagram must be destroyed. This field is modified in Internet header processing. The time is measured in units of seconds. However, since every module that processes a datagram must decrease the TTL by at least one (even if it processes the datagram in less than 1 second).
This value represents number of hops that the IP datagram will go through before being discarded.
Whenever an IP packet passes through a router, the router will decrease the TTL by one; if the TTL ever reaches 0, the packet will be thrown away under the assumption that it must be undeliverable as it hasn't been delivered by now. The original TTL value depends upon the operating system; your FreeBSD system uses a default TTL of 64. Since this is an 8-bit field, the maximum allowable TTL is 255 (2 to the power of 8 minus 1; the minus 1 is for the non-allowable TTL of 0).
Protocol(8 bits)
Indicates the next level protocol used in the data portion of the Internet datagram.
This field represents the transport layer protocol that handed over data to IP layer. This field comes in handy when the data is demultiplex-ed at the destination as in that case IP would need to know which protocol to hand over the data to.
Note: check for protocol numbers.
Header Checksum(16 bits)
A checksum on the header only. Since some header fields change, e.g., Time To Live, this is recomputed and verified at each point that the Internet header is processed.
Whenever an IP header is created or modified, a CRC (cyclic redundancy check) is run on the bits contained within the IP header. Basically, some math (the CRC algorithm) is done which results in an answer known as the checksum. When the IP packet is received, the same CRC is repeated on the header; if this results in the same answer (checksum), all of the bits of the IP header must have arrived in the correct order. If the CRC results in a different checksum, some of the bits in the header didn't arrive, meaning the IP packet was somehow damaged during transit.
Source and destination IP(32 bits each)
These fields store the source and destination address respectively. Since size of these fields is 32 bits each so an IP address os maximum length of 32 bits can be used.
Source: This will be the IP address of the host that sent the IP packet.
Destination: This will be the IP address of the host that is to receive the data contained within the IP packet.
Options and Padding(Variable length)
This is the only field in an IP packet which is optional, as all other fields are mandatory. This field is used to provide special delivery instructions not covered by the other fields in an IP header. It can allow for up to 40 bytes worth of extra instructions; these instructions must be in 32-bit words. If an instruction doesn't quite fill up a 32-bit word, the missing bits will be filled in with "padding" bits.
The option field is variable in length. There may be zero or more options. There are two possible formats for an option:
Data:
Data:
This field contains the data from the protocol layer that has handed over the data to IP layer. Generally this data field contains the header and data of the transport layer protocols. Please note that each TCP/IP layer protocol attaches its own header at the beginning of the data it receives from other layers in case of source host and in case of destination host each protocol strips its own header and sends the rest of the data to the next layer.
This will be the actual data that is being sent from one host to another.
Internet Protocol being a layer-3 protocol (OSI) takes data Segments from layer-4 (Transport) and divides it into packets. IP packet encapsulates data unit received from above layer and add to its own header information.
IP header includes many relevant information including Version Number, which, in this context, is 4. Other details are as follows:
Version: Version no. of Internet Protocol used(e.g. IPv4).
IHL: Internet Header Length; Length of entire IP header.
DSCP: Differentiated Services Code Point; this is Type of
Service.
Service.
ECN: Explicit Congestion Notification;
It carries information about the congestion seen in the route.
Total Length: Length of entire IP Packet
(including IP header and IP Payload).
Identification: If IP packet is fragmented during the
transmission, all the fragments contain
same identification number. To identify original
IP packet they belong to.
Flags: As required by the network resources,
if IP Packet is too large to handle, these ‘flags’
tells if they can be fragmented or not.
In this 3-bit flag, the MSB is always set to ‘0’.
Fragment Offset: This offset tells the exact position
of the fragment in the original IP Packet.
Time to Live: To avoid looping in the network,
every packet is sent with some TTL value set,
which tells the network how many routers (hops)
this packet can cross.
At each hop, its value is decremented by one and
when the value reaches zero, the packet is discarded.
Protocol: Tells the Network layer at the destination host,
to which Protocol this packet belongs to,
i.e. the next level Protocol.
For example protocol number of ICMP is 1, TCP is 6 and UDP is 17.
Header Checksum: This field is used to keep checksum value
of entire header which is then used to check if
the packet is received error-free.
Source Address: 32-bit address of the Sender(or source)
of the packet.
Destination Address: 32-bit address of the Receiver
(or destination) of the packet.
Options: This is optional field, which is used if the
value of IHL is greater than 5.
These options may contain values for options
such as Security, Record Route, Time Stamp, etc.
value of IHL is greater than 5.
These options may contain values for options
such as Security, Record Route, Time Stamp, etc.
TCP Protocol Layers Explained
Now that we've examined what is contained in a Layer 3 (IP) header, let's move on to the Layer 4 header. A Layer 4 header occurs at the very beginning of the IP data field and can be either a TCP header or a UDP header. Let's start with the fields that will be found in a Layer 4 TCP header:
Note that a TCP header is also composed of 32-bit words; like an IP header, the default size is 20 bytes if the option field is not used. Let's summarize the fields that are available in a TCP header:
Source Port
This 16-bit number represents the name of the application that sent the data in the IP packet. On your FreeBSD system, the file /etc/services lists which applications use which port numbers.
This 16-bit number represents the name of the application that sent the data in the IP packet. On your FreeBSD system, the file /etc/services lists which applications use which port numbers.
Destination Port
This 16-bit number represents the name of the application that is to receive the data contained within the IP packet. This is one of the major differences between a Layer 3 and a Layer 4 header: the Layer 3 header contains the IP address of the computer that is to receive the IP packet; once that packet has been received, the port address in the Layer 4 header ensures that the data contained within that IP packet is passed to the correct application on that computer.
Sequence Number
TCP is responsible for ensuring that all IP packets sent are actually received. When an application's data is packaged into IP packets, TCP will give each IP packet a sequence number. Once all the packets have arrived at the receiving computer, TCP uses the number in this 32-bit field to ensure that all of the packets actually arrived and are in the correct sequence.
This 16-bit number represents the name of the application that is to receive the data contained within the IP packet. This is one of the major differences between a Layer 3 and a Layer 4 header: the Layer 3 header contains the IP address of the computer that is to receive the IP packet; once that packet has been received, the port address in the Layer 4 header ensures that the data contained within that IP packet is passed to the correct application on that computer.
Sequence Number
TCP is responsible for ensuring that all IP packets sent are actually received. When an application's data is packaged into IP packets, TCP will give each IP packet a sequence number. Once all the packets have arrived at the receiving computer, TCP uses the number in this 32-bit field to ensure that all of the packets actually arrived and are in the correct sequence.
Acknowledgement Number
This number is used by the receiving computer to acknowledge which packets have successfully arrived. This number will be the sequence number of the next packet the receiver is ready to receive.
Header Length or Offset
This is identical in concept to the header length in an IP packet, except this time it indicates the length of the TCP header.
Reserved
These 6 bits are unused and are always set to 0.
This number is used by the receiving computer to acknowledge which packets have successfully arrived. This number will be the sequence number of the next packet the receiver is ready to receive.
Header Length or Offset
This is identical in concept to the header length in an IP packet, except this time it indicates the length of the TCP header.
Reserved
These 6 bits are unused and are always set to 0.
Control Flags
TCP uses six control flags with each flag being a unique bit. If the bit is set to 1, the flag is on; if the bit is set to 0, the flag is off. The order of the flags is:
URGent
ACKnowledgement
PuSH
ReSeT
SYNchronize
FINish
TCP uses six control flags with each flag being a unique bit. If the bit is set to 1, the flag is on; if the bit is set to 0, the flag is off. The order of the flags is:
URGent
ACKnowledgement
PuSH
ReSeT
SYNchronize
FINish
U (URG) Urgent pointer field significant.
A (ACK) Acknowledgment field significant.
P (PSH) Push function.
R (RST) Reset the connection.
S (SYN) Synchronize sequence numbers.
F (FIN) No more data from sender.
We'll be seeing these flags again when we run "tcpdump" and when we take a look at creating packet filter rules.
Window Size
Every TCP packet contains this 16-bit value that indicates how many octets it can receive at once. When IP packets are received, they are placed in a temporary area of RAM known as a buffer until the receiving computer has a chance to process them; this value represents how big a buffer the receiving host has made available for this temporary storage of IP packets.
A (ACK) Acknowledgment field significant.
P (PSH) Push function.
R (RST) Reset the connection.
S (SYN) Synchronize sequence numbers.
F (FIN) No more data from sender.
We'll be seeing these flags again when we run "tcpdump" and when we take a look at creating packet filter rules.
Window Size
Every TCP packet contains this 16-bit value that indicates how many octets it can receive at once. When IP packets are received, they are placed in a temporary area of RAM known as a buffer until the receiving computer has a chance to process them; this value represents how big a buffer the receiving host has made available for this temporary storage of IP packets.
Checksum
Unlike IP, TCP is responsible for ensuring that the entire IP packet arrived intact. TCP will run a CRC on the entire IP packet (not just the header) and place the resulting checksum in this field. When the IP packet is received, TCP re-runs the CRC on the entire packet to ensure the checksum is the same.
Urgent Pointer
If the Urgent flag was set to on, this value will indicate where the urgent data is located.
Options and Padding
Like IP options, this field is optional and represents additional instructions not covered in the other TCP fields. Again, if an option does not fill up a 32-bit word, it will be filled in with padding bits.
Data
This will be the actual data being sent and will not include any additional headers.
Finally, let's take a look at a Layer 4 UDP header. Unlike TCP, UDP does not create a connection or guarantee the delivery of data. Accordingly, a UDP header has very few fields as compared to a TCP header:
Unlike IP, TCP is responsible for ensuring that the entire IP packet arrived intact. TCP will run a CRC on the entire IP packet (not just the header) and place the resulting checksum in this field. When the IP packet is received, TCP re-runs the CRC on the entire packet to ensure the checksum is the same.
Urgent Pointer
If the Urgent flag was set to on, this value will indicate where the urgent data is located.
Options and Padding
Like IP options, this field is optional and represents additional instructions not covered in the other TCP fields. Again, if an option does not fill up a 32-bit word, it will be filled in with padding bits.
Data
This will be the actual data being sent and will not include any additional headers.
Finally, let's take a look at a Layer 4 UDP header. Unlike TCP, UDP does not create a connection or guarantee the delivery of data. Accordingly, a UDP header has very few fields as compared to a TCP header:
A UDP header is always 8 bytes as it does not contain any options. The UDP header fields are as follows:
Source Port
Like TCP, this field indicates which application sent the data contained within the IP packet.
Destination Port
Again, indicates which application is to receive the data contained within the IP packet.
Length
Indicates the length (in bytes) of the UDP header and the data. Since all UDP headers are 8 bytes long, if you subtract 8 from this number you'll find out the size of the data being sent.
Checksum
Since UDP is not responsible for ensuring that the data actually arrives, a checksum is optional; if it is not used, this field will be set to 0.
Source Port
Like TCP, this field indicates which application sent the data contained within the IP packet.
Destination Port
Again, indicates which application is to receive the data contained within the IP packet.
Length
Indicates the length (in bytes) of the UDP header and the data. Since all UDP headers are 8 bytes long, if you subtract 8 from this number you'll find out the size of the data being sent.
Checksum
Since UDP is not responsible for ensuring that the data actually arrives, a checksum is optional; if it is not used, this field will be set to 0.
Data
Again, this will be the actual data being sent and will not include any additional headers.
Again, this will be the actual data being sent and will not include any additional headers.
