What is the smallest set of TCP/IP protocols required to implement TCP

I'm writing my own network stack. I will only be receiving TCP data. What is the bare minimum TCP/IP protocols to implement TCP?

I thought it would be:

• Ethernet
• TCP
• IP
• UDP
• DNS (gethostbyname)
• ARP (not knowing MAC addresses)
• DHCP (be assigned an IP address)

However, this wikipedia page:

https://en.wikipedia.org/wiki/Internet_protocol_suite#:~:text=A%20minimal%20implementation%20of%20TCP,Group%20Management%20Protocol%20(IGMP).

says:

> A minimal implementation of TCP/IP includes the following: Internet Protocol (IP), Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Group Management Protocol (IGMP). In addition to IP, ICMP, TCP, UDP, Internet Protocol version 6 requires Neighbor Discovery Protocol (NDP), ICMPv6, and Multicast Listener Discovery (MLD) and is often accompanied by an integrated IPSec security layer.

What is the smallest practical set of protocols to receive TCP data?

TCP requires IPv4 or IPv6, although there is an RFC to run on IPX, but I do not think anyone ever really implemented it.

IP (both versions) does not require any particular data-link protocols, such as ethernet. It can run on any data-link protocol (ethernet, Wi-Fi, token ring, FDDI, PPP, ATM, HDLC, frame relay, etc.).

UDP is a parallel transport protocol, and you do not use it, or any other transport protocol (SCTP, DCCP, etc.) for TCP.

ARP is only used for IPv4 (IPv6 uses NDP) on some, but not all, data-link protocols.

DHCP is not a requirement. It is used as one method of configuring a host, but there are other methods.

Also, ICMP is an integral part of IP (both versions). "ICMP, uses the basic support of IP as if it were a higher level protocol, however, ICMP is actually an integral part of IP, and must be implemented by every IP module."

Instead of thinking about "which protocols to implement?" I suggest thinking about which packets you will receive and what to do with them. You can take a lot of shortcuts.

I assume Ethernet, and IPv4, not IPv6.

The very first thing your device must do is understand ARP requests (Ethernet+ARP) and send ARP replies, so other devices can find your device's MAC address based on its IP address. When another device wants to send an IP packet to yours the first thing it will do is find the MAC address by using ARP. The MAC address is saved by that device for a while, so it doesn't send one every time.

There's not very much work to ARP. Your device just checks a bunch of header fields to ensure that it's addressed to your device, then swaps some around to return to sender, inserts its own MAC address into the reply and sends it back out.

You can take a little detour and make your device understand ping requests (Ethernet+IP+ICMP) and send ping replies. It's basically the same process as ARP. IP has a checksum, which you need to calculate based on the packet contents. (Once you have that working in packets you send, you may as well also check the checksum of packets your device receives). Then you can ping your device and get some tangible results on the screen.

When you send a reply you need a MAC address to send it to, which a proper stack would get by using ARP, but why bother with that - just use the same address that sent the request to you!

For TCP your device needs to also understand TCP packets (Ethernet+IP+TCP). Because you only want to receive data you don't have as much work to do. You want to keep track of connections that are open, since each connection works independently.

• When you get a SYN packet, that's a new connection so remember it and remember what sequence number that was (+1 because the SYN counts as a sequence number) and send a SYN+ACK.
• When you get any other packet, if its sequence number is the sequence number you remembered, then this packet is in the right sequence, so process the data and update the remembered sequence number.
• No matter what (even if the sequence number is wrong), send an ACK back, with the ACK number being the remembered sequence number (the one you want to see in the next packet).
• If you get a FIN, send FIN+ACK (even if you don't know the connection) and forget the connection.
• If you get a packet and you don't recognize the connection and it doesn't have SYN, send RST.

Again, whenever you send a reply, just use the same MAC address that you got the packet from. Because your device only receives, it never needs to send an ARP request to find a MAC address.

I want to emphasize this is a really dumb algorithm for TCP taking lots of shortcuts, but it does work - I have actually implemented this on a device and connected to it. I may have made some small mistakes here compared to what I implemented.

DHCP is a way to make your device ask the router for an IP address. You don't need it. Just hard-code an IP address.

DNS is a way to convert names to IP addresses. You don't need it. But if you did need it, it would be between you and a DNS server to look up the device's address - the device doesn't participate in that. If your device wanted to look up IP addresses using DNS names, it would need to know DNS.