TCP/IP Notes

Intro / Network Addressing / Network Addressing IPv6 / Packet Headers / Networking and Data Link Layers / Transport Layer Protocols / Application Layer Protocols / IP Routing / ICMP / DHCP / Name Resolution and DNS / Security

TRANSPORT LAYER PROTOCOLS

While the Network Layer is concerned with networking, addressing, routing, and delivery, the Transport Layer protocols (Transmission Control Protocol and User Datagram Protocol) are concerned with inter-network communication.


OSI Model	TCP/IP Model (DoD Model)	TCP/IP – Internet Protocol Suite

Application		Telnet, SMTP, POP3,
Presentation	Application	FTP, NNTP, HTTP,
Session		SNMP, DNS, SSH,…
Transport	Transport	TCP, UDP
Network	Internet	IP, ICMP, ARP, DHCP
Data Link	Network Access	Ethernet, PPP, ADSL
Physical

TCP and UDP work together but perform different roles for what is essentially the same function, and both support IP in the Network Layer. Whereas IP is considered 'connectionless' and by itself does not have any guarantee that a message reaches its destination, TCP provides connection-oriented reliable addressing. One area where TCP and UDP differ is that UDP is used for applications which do not require delivery verification. The trade-offs between this are time and bandwidth consumption; it takes longer time and more bandwidth to mete out this verification and provide a completely connection-oriented line of communication. The former type of connection-less protocols use a method called 'best effort delivery' in that no error checking or retransmission of the original message occurs, but rather simply packages messages "as is." For UDP-oriented applications, there are generally built-in timeout values and retry counters. For this reason UDP runs about 40% faster than TCP. In order for a sequence of UDP datagrams to go from point A to point B, the MTU is checked, and the Application Layer deals with error issues and reassembly.

Connection-less protocols typically handle the following:

Message checksum - allows Transport Layer protocol to report to a higher-layer protocol whether the packet traveled between hosts in the same form.

Higher-layer protocol identification - TCP/IP Transport Layer protocols use source and destination port address fields to match messages to the corresponding port for the sending and receiving hosts upon reception at the Application Layer.

Although many protocols have been updated for IPv6, UDP is functionally similar (has not been updated independently for the new version), but does allow greater functionality in terms of jumbogram handling.

netstat -sp udp will return connection statistics for UDP in IPv4, and netstat -sp udpv6 for IPv6 (https://ss64.com/bash/netstat.html).

One difference between UDP over IPv4 and UDP over IPv6 is that in IPv6 the UDP checksum is required rather than optional.

TCP with IPv4 & IPv6
---------------------------

TCP as a connection-oriented protocol with end-to-end reliability does the following:

- Create logical connection directly between two peers on an internetwork.
- Track transfer of data and make sure it arrives successfully via acknowledgements and sequence number tracking.
- Identify amount of data transferred (as well as out-of-order packets).
- Include a timeout mechanism (host will drop connection if wait is too long).
- Include a retry mechanism by retransmission of data.

Client-server TCP model

TCP hosts create virtual connections using a handshake process in which sequence numbers track data as it goes from one host to the next. TCP doesn't know what message it's carrying (this is for the upper-layer protocols to determine), it simply transfers the data as a continuous stream of bytes. The maximum TCP segment size is 65,496 bytes (20 byte IP header and 20 byte TCP header subtracted from the Total Length Size field value).

Like UDP, TCP is essentially unchanged in IPv6, but may be used differently as in the case of jumbograms. To accommodate the larger size of the IPv6 header, TCP over IPv6 must change the maximum segment size (MSS) by subtracting 60 octets (20 for TCP header and 40 for minimum length IPv6 header) rather than 40 which is the case in IPv4.

MSS is different from MTU in that MSS is the amount of data which can fit into a packet after the TCP header, while MTU is the amount of data which can fit inside the MAC header.

User Datagram Protocol (UDP)
-----------------------------------------

UDP was originally specified by RFC 768 (https://tools.ietf.org/html/rfc768) in 1980. It has no reliability mechanisms, no delivery guarantees, no connection handling, no buffering service and no segmentation, however these apparent disadvantages inherent in the 'connection-less' UDP protocol are handled by the Application Layer.

In the IP header, when the Protocol field contains the value 17 (0x11), the UDP header follows. The UDP header is 8 bytes and serves merely to define the process or application that is using IP/UDP and the Network/Transport layers.

Source Port Number field - defines application or process which sends the packet.

Destination Port Number field - defines destination application/process for receiving host. In some cases, the source and destination port numbers are the same, in other cases such as DHCP they are different. The most common configuration is to have the client use a dynamic port number and the server a well-known or registered port number.

Length field - defines the length of the packet from UDP header to the end of valid data (redundant measurement since this can also be determined by IP header).

Checksum field - optional, contains pseudo-header (derived from IP header), used to calculate UDP header checksum and associate UDP header with IP header.

UDP and TCP use port numbers to define source and destination addresses (processes/applications).

Port numbers are defined in three ranges: well-known, registered, and dynamic (https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers).

Well-known port #'s (0-1023) - Assigned to core services (DHCP, SNMP, RIP, etc.)

Registered port #'s (1024-49151) - Assigned to industry applications and processes (SQL Server, Cisco, Adobe, OpenVPN, etc.)

Dynamic Port #'s (49152-65535) - Used as temporary ports for specific communications while engaged.

Whenever connection-oriented communication features are unnecessary (e.g. routing, advertisement, polling, etc.) UDP will be used to favor speed over reliability.

UDP over IPv6
-------------------

In IPv6 UDP isn't much changed, but is treated differently compared with IPv4. Namely, UDP over IPv6 must support 128 bit addresses rather than 32 (similar to TCP over IPv6). The pseudo-header is used in this situation to contain all of the relevant information from the UDP header: source/destination port #, length and checksum.

The fields for the pesudo-header are similar to IPv4 UDP headers:

128-bit IPv6	source address
128-bit IPv6	destination address
32-bit upper layer	protocol packet length
0	8-bit protocol
16-bit UDP source port	16-bit UDP destination port
16-bit UDP length	16-bit UDP checksum
Data	(and possible pad byte)

Source Address field - Taken from IPv6 header.

Destination Address field - Address if the IPv6 packet does not have a routing header. If it does, this equals the last element in the routing header of the originating host.

UDP Length field - Length of the UDP header plus the data the UDP header contains.

Next Header field - Value of the protocol (UDP, 17).

Source Port field - Number used by sending host (0 if no reply is needed).

Destination Port field - Port used by receiving node, accepts data as long as port is active.

Length field - Length of UDP header plus data in bytes (value in UDP pseudo-header Length field).

Checksum field - Error checking header and data (required for IPv6). When the checksum is calculated, the hex value of FFFF is put in the UDP header if the value is zero causing the packet to be discarded at the receiving end.

Data field - Contains the data.

Transmission Control Protocol (TCP)
-----------------------------------------------

TCP is one of the original protocols of the Transport Layer which works with IP to provide reliable transportation of network traffic. A three-way handshake procedure enables the connection process between nodes to occur. When host A initiates a connection with host B, it first ensures that the destination host is available (listening status on destination port), and informs the receiving host of the sender sequence number enabling the two hosts to unite.

TCP handshake

1) The sending host sends a TCP packet which does not contain any data but rather the sending host's starting sequence number (SYN bit setting of 1), source and destination port numbers, and the MSS that can fit into each TCP packet.

2) The receiving host responds with its own starting sequence number and indication of MSS. The Acknowledgement bit is set to 1 in the reply to acknowledge reception of step 1 (ACK).

3) Sending host acknowledges this receipt, completing the handshake process.

In cases there can be a half-open connection, meaning the final ACK message doesn't properly end the handshake:

SYN >>>>>

When this happens, the sending host doesn't send the post-ACK message back to the receiving host, leaving the receiving host to resend an ACK SYN packet. One form of a DoS attack involves using this method (referred to as a two-way handshake) to overload the destination host.

TCP Keep-Alive Process
-------------------------------

Once a TCP connection is established, a keep-alive process maintains the connection to eliminate the need to repeat the handshake process. The Application Layer may perform part of this role but it can be implemented in TCP.

In Windows operating systems TCP keep-alives are disabled by default (in Linux parameters can be configured within the kernel), however applications can perform this process as part of a programming function. Registry settings within Windows allows the administrator to configure the parameters of this function.

TCP Connection Termination
-------------------------------------

This process requires 4 packets.

1) The sending host sends a TCP packet with the FIN ("finish") & ACK flags set.

2) The receiving host sends an ACK back in reply.

3) The receiving host sends a TCP packet with FIN & ACK flags set.

4) The sending host returns an ACK response.

Other TCP Connection States
--------------------------------------

(https://upload.wikimedia.org/wikipedia/commons/a/a2/Tcp_state_diagram_fixed.svg)

Other connection states include:

CLOSED - no TCP connection.

LISTEN - destination host listening/ready to accept port communication.

SYN SENT - host sent a SYN packet.

SYN RECD - host received SYN packet and sent SYN-ACK response.

ESTABLISHED - three-way handshake completed successfully.

FIN-WAIT-1 - first FIN-ACK packet to close a connection was sent.

FIN-WAIT-2 - host sent FIN-ACK packet and received ACK response.

CLOSE WAIT - host received FIN-ACK and sent FIN-ACK (passive close).

LAST ACK - host sent an ACK in response to the FIN-ACK it received.

CLOSING - FIN-ACK packet was received, but the ACK value doesn't match the FIN-ACK sent (both sides are attempting to close the communication at the same time).

TIME WAIT - both sending and receiving hosts send FIN-ACK and ACK messages (connection is closed, but hosts must wait before reusing connection parameters).

TCP Sequence and Acknowledgement Process
-------------------------------------------------------------

Process which guarantees packets are ordered and protects against missing segments. During the handshake process, sequence numbers are incremented according to the amount of data in the next packet being sent:

Sequence Number In + Bytes of Data Received = Acknowledgement Number Out

TCP Error-Detection and Error-Recovery Process
----------------------------------------------------------------

When a communication sequence fails, TCP has built-in functions to determine the error and to recover the transmission. First, the retransmission timer sets a retransmission timeout (RTO), prompted by the sending of data (each time data is transferred, the timeout starts & conversely received replies stop the timer). When the timer runs out (no ACK reply for data sent is received), the sending host retransmits the first TCP data segment, prompting the sender to double its RTO value, continuing until the limit is reached.

TCP Congestion Control
-------------------------------

Congestion refers to overloading a network or receiving host, when the number of bytes is greater than the advertised window (defined in Window field of receiving host TCP header) and occurs when too much data is being sent across a network medium, resulting in packet loss. Receiving hosts place data into a TCP buffer area, which is accessed by the Application Layer protocol. Congestion control mechanisms in place:

TCP supports 'windowing,' which allows TCP sequence packets to be sent without waiting for an acknowledgement. This value is based on the amount of traffic the network is capable of supporting (congestion window) and receiving host's available buffer space (advertised window).

Slow Start/Congestion Avoidance - Generally the initial value of the window being used for the receiving host is twice the value of the sending host's MSS. The window size increases due to the Slow Start algorithm. If a timeout occurs which signifies an error, the window size is divided in half. Then, a Congestion Avoidance algorithm increases the window size in a linear fashion. When three or more duplicate ACK processes are detected a timeout event occurs.

Fast Retransmit/Fast Recovery - When an out-of-order segment is received, the Fast Transmit process instructs the receiving host to send duplicate ACK messages, indicating which sequence number was expected. The Fast Recovery process instructs the receiving host to retransmit the lost segments of data.

TCP Sliding Window - TCP uses this method for data transmission to determine the amount of unacknowledged data from the point of view of the receiver (not to be confused with the advertised window which is an indication of buffer space). Essentially the sliding window concept can be divided between data which was sent and acknowledged, data sent and waiting to be acknowledged, and waiting for the window to move before a sending host sends the next piece of data.

In some cases Silly Window Syndrome (SWS) can develop in which a receiving buffer is filled leaving it in a zero-window state. This causes the receiving host to advertise a window size of 0 until the Application Layer retrieves 1 byte from the buffer (causing the host to advertise a word size of 1 and the sender to transmit a single byte of information). This can be avoided by receiving hosts not advertising new window sizes until available buffer space at least equals MSS, and by sending hosts not sending data until the advertised window is at least the size of the MSS value.

TCP Header Fields
------------------------

Source Port Number field - Same as in UDP.

Destination Port Number field - Same as in UDP.

Sequence Number field - Contains a number uniquely identifying TCP segment, enables TCP receiving host to identify when segments of a data stream are missing. This number is incremented by the number of data bytes contained in the packet. The initial sequence number used is defined by the host and should be randomly assigned for security. TCP connections can be hijacked via sequence number prediction.

Acknowledgement Number field - Indicates next expected sequence number from receiving host.

Header Length field - Defines length of TCP header in 4-byte increments.

Flags field - Flag settings used in TCP header:

URG (urgent) - Tells receiver where to start reading bytes contained in data portion of the packet.
ACK
PSH (push) - Used for time-critical applications, causes receiver not to buffer data and pass it to Application Layer protocol. Normally reserved for final TCP segment in a sequence.
(Reset) - Closes/refuses connection.
SYN
FIN (finish) - Indicates that host has completed transaction.

Window Size field - Indicates the size of the receiving buffer in bytes.

Checksum field - Performed on the contents of the TCP header/data, and the pseudo-header derived from the IP header. The TCP pesudo-header contains IP header Source Address field, IP Destination Address field, the Protocol field value, and from the TCP header the value of the Length field.

Urgent Pointer field - Relevant only if URG pointer is set, tells the receiving host where to read in the packet.

TCP Options field - Optional field (https://iana.org/assignments/tcp-parameters), can be used for MSS.

TCP and IPv6
-----------------

Similar to UDP there is no new version of TCP specifically for IPv6; the only difference is in the way IPv6 works with TCP compared with IPv4. For example, TCP must accommodate a 128-bit address, and since checksums for UDP and TCP are mandatory rather than optional under IPv6, TCP uses an IPv6 pseudo-header. In the Length field the value is the same as the Payload Length field in the IPv6 header (subtracted by the length of any extension headers). The other fields are the same as in the IPv6 pseudo-header for UDP. The standard TCP header is exactly the same for IPv6 as it is for IPv4.

UDP, TCP, and IPv6 Extension Headers
---------------------------------------------------

IPv6 extension headers contain optional Internet-layer data stored in separate headers between the IPv6 header and the upper-layer transport pseudo-header. The IPv6 header and extension header (if present) contain a Next Header field. If no optional extension headers are used, this field contains the value of the upper-layer protocol used in IPv6 (UDP or TCP). The IPv6 packet can include more than one optional extension header, and each of the headers is present are sandwiched between the IPv6 header and the IPv6 pseudo-header for UDP/TCP. Each extension header contains a Next Header field value specifying the next extension header in the stack:

(Cisco image: https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html)

Overhead remains the main factor in choosing to use UDP (unreliable) or TCP (reliable), especially from the point of view of the Application layer. TCP inherently contains more meta-data and connection-centric information. Since applications are different in terms of requirements, especially given broadcast or multicast communications, UDP may be preferable. For other applications such as RIP whose only job is to periodically update routing tables and track timeout values, the extra reliability of TCP may be unnecessary. From the development side, built-in reliability mechanisms may be used.

TCP was designed when 300-bps communication was considered fast, and while for a local network TCP may be entirely unnecessary, the Internet makes TCP retain its inherent value (reliability and robustness). In general, it's going to be faster to handle robustness and reliability issues at the hardware rather than software level, and with the introduction of cell-oriented transmission technologies such as ATM and SONET, there are some who believe TCP might eventually become obsolete, but for the time being it remains one of the single most important protocols driving the Internet.

Further Reading
---------------------

UDP – User Datagram Protocol
https://www.ipv6.com/general/udp-user-datagram-protocol/

TCP keepalive overview
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html

Using TCP keepalive under Linux
https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html

TCPIP IPv4 settings
https://www.ibm.com/support/knowledgecenter/en/linuxonibm/liaag/wkvm/wkvm_c_tune_tcpip.htm

Understanding TCP Sequence and Acknowledgment Numbers
https://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/

Network congestion
https://en.wikipedia.org/wiki/Network_congestion

TCP Congestion Control
https://www.net.t-labs.tu-berlin.de/teaching/computer_networking/03.07.htm

RFC 5681: TCP Congestion Control
https://tools.ietf.org/html/rfc5681

Slow Start
https://en.wikipedia.org/wiki/Slow-start

TCP Congestion-Avoidance
https://en.wikipedia.org/wiki/TCP_congestion-avoidance_algorithm

IPv6 Extension Headers Review and Considerations
https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html