I'm studying the difference between the protocols IP and TCP. IP is said to provide an unreliable datagram service whereas TCP provides a reliable bytestream service. Further, TCP works on top of IP. So my question is, can the protocol IP be used solely to send packets (without passing through TCP protocols) ?
I think there is a little bit of confusion when it comes to some networking fundamentals here: first you say that "TCP works on top of IP", which is correct, and then you ask if it's possible for IP to send packets "without passing through TCP protocols".
Since IP works at a lower OSI layer than TCP (IP is a level 3 protocol while TCP is a level 4 protocol), it's TCP data that gets encapsulated by IP, not viceversa. Every OSI layer (and TCP/IP layer for that matter), provides services to the layers above it and sends data to the layers below it.
So yes, IP can send data without using TCP, it's TCP data that cannot avoid going through the IP layer.
Note that potentially, another Level 3 protocol could be used, IP just so happens to be the most widely used one.
[summarizing the question]
Can I communicate with raw IP datagrams, without a transport layer?
- It's an exceptionally strange way to build an application (you'd have to tell your OS NIC driver to send packets having used [IP protocol numbers] to their proper kernel driver, make your egress data avoid collision with existing IP protocol numbers, and queue all other packets directly to your application buffers).
- You should not bother entertaining this idea other than the time it takes to read this sentence.
Perhaps you want to know why...
- This answer assumes all applications communicate with IPv4; we will ignore IPv6 (which uses similar dynamics) and ignore raw ethernet protocols.
- After IP data arrives at the endpoint address, you need to know which application to deliver it to; that means
most peopleeverybody want more than "just an IP address" to identify the application. Why everybody? If you only use your IP address to identify the application, you have to filter out a mountain of "normal" application traffic that also happens to use your application id, like DNS, ssh, ping, etc... Why would you build your application with so much noise in the channel?
Transport protocols such as TCP and UDP use port numbers to multiplex applications on a single address; occasionally people use an IP Protocol number (but the IP protocol header is only 8-bits wide). In all cases though, you must put something in the IP protocol field (even if that's going to be ignored by your host as you proposed).
Most IP protocols are wasted space in a very small field:
Another interesting thing about that IP protocol number list: at least 50% of those protocols with a dedicated 8-bit IP protocol number are archaeological relics of the internet (read: wasted protocol numbers).
Rhetorical question: When was the last time you heard of someone using Network Voice Protocol (IP protocol 11) or Host Monitoring Protocol (IP Protocol 20)? Nobody does, they use SIP for voice (both TCP and UDP) or ping (ICMP) for host monitoring.
List of common IP protocols:
Nearly every application I can think of uses one of the following IPv4 protocols (in rough order of frequency people see on the wire):
- TCP (IP Protocol 6)
- UDP (IP Protocol 17)
- ICMP (IP Protocol 1)
- OSPF (IP Protocol 89)
- EIGRP (IP Protocol 88)
- GRE (IP Protocol 47)
- ESP (IP Protoocl 50)
- AH (IP Protocol 51)
- PIM (IP Protocol 103)
- IGMP (IP Protocol 2)
- VRRP (IP Protocol 112)
- SCTP (IP Protoocl 132)
That's it... statistically, every other IP protocol ranks in noise... and if it wasn't obvious enough, every one of those protocols performs at least one of the functions of an IP Transport protocol. This simply reinforces the fact that while "you can build your own protocols inside of raw IP payload if you want. Very few people should want to". Doing so dedicates your IP address to a single application, and probably is going to "reinvent the wheel" in several ways.
Summary: Most people should use TCP (because of its advanced error recovery, data acknowledgment, MSS negotiation, and flow control). A few should use UDP, or SCTP. The rest will multiplex their protocol with ethertype or IP protocol. Nobody should solely identify their app with the host IP address.
TCP doesn't actually send packets. It uses segments, which are sequenced messages sent between hosts by IP in packets.
IP is how the data (TCP, UDP, or other) makes it from one host to another ... it is the forwarding. TCP specifies how those hosts implement a reliable connection over a packet-based network layer with no delivery guarantee, with sequencing, windowing, and retransmission.
It may sound weird but once you get used to the idea that "TCP packet" is shorthand for "TCP segments carried within IP packets" and "UDP packets" is shorthand for "UDP datagrams within IP packets", it becomes less confusing.
TCP and IP are at different layers in the OSI model; TCP a layer 4 protocol, the transport layer, and IP is one below from layer 3, a network protocol.
Each layer in the model performs a specific function so it might help to have a quick description of each layer:
Layer 3 (Network) - Defines functions and procedures for transferring variable length data sequences from one node to another on a network. Basically this layer is just about sending the data given to it from higher layers to the destination, there is no reliability here. Addressing and routing live at this layer. Example protocols: IPv4, IPv6, IPsec, AppleTalk.
Layer 4 (Transport) - The OSI defines this layer as protocols that define functions and procedures for transferring variable length data sequences from one node to another on a network while maintaining Quality of Service functions. This layer is all about getting data to the far end as reliably as required, TCP provides delivery assurance and flow control, UDP doesn't for example. Example protocols: TCP, UDP, L2TP.
So lets look at an IP packets header (From RFC 791):
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notice on the third line of the header there is a protocol section, here the packet describes which layer 4 protocol is contained within the packet, some examples possible are (Full List):
Decimal Protocol Name ------- ---------------- 1 ICMP 6 TCP 17 UDP 88 EIGRP 89 OSPFIGP
So to sum up, yes you can send data without using TCP. :)
A comment about "X is Reliable".
"IP (or UDP) is unreliable" means there is no built-in mechanism to see data loss. Many protocols over UDP use their own mechanisms to detect (and possibly correct) the data loss: perhaps the simplest is sequence numbers in syslog messages ("
: %SYS-5-CONFIG_I: Configured from console by vty2 (10.34.195.36)"
"TCP provides reliability" means that it provides a promise to the sender that data will be delivered reliably if it's possible given the underlying transport. This is at the expense of taking more time. It's like a courier's proof-of-delivery: they keep trying to deliver it, and if it gets there, and the proof reached you, then you know it was delivered. If the outward transmission or the return acknowledgement fails, you don't know it was delivered, but it might have been.
TCP adds a ready-made reliable-delivery-notification mechanism, as well as turning lumpy packet transmission into byte streams, which are usually more useful.
"Ethernet is reliable" on the other hand, normally means the actual number of errors is very low. Both a) the receiver knows its frames haven't been corrupted (because of checksums), and b) in practice, the actual error rate is very low (because switches prevent collisions, electrical spec is excellent and covers many source of error. All the routers' interfaces I just looked at have byte counts in the gigabytes and zero errors of any kind; the actual specs require bit error rates from about 10^-10 to 10^-13 depending on medium, speed etc.
TCP can only deliver reliability if the transport permits it. Consider "is there a host at 188.8.131.52?": with 99% packet loss TCP (eg HTTP) will probably fail to get any bytes delivered; ping or UDP on the other hand, will quite likely get a packet through and back eventually. The difference between "is it off" and "is it performing very badly" can be important.
Finally, you have to consider what you want to happen when packets are lost. If it's to retry until something gets there, TCP is excellent. If -- such as in live audio such as a phone call -- the only thing to do is throw away late data, TCP is no good, and most streaming uses UDP with its own error detection.
An additional aspect to the already present answers:
The ubiquity of network address translation for IPv4 (NAT) has effectively stopped the adoption of new transport-layer protocols. Simply put, a NAT router requires some inside knowledge about a transport protocol (esp. port handling) for source NAT to work. Accordingly, new protocols don't work on legacy hardware and cannot be used. As a workaround, most new protocols (like QUIC) ride on top of UDP.
Even if a NAT router is smart enough to translate outgoing packet for an unknown protocol (that you've just invented five minutes ago), it can only do so for a single private node. Lacking the inside knownledge mentioned above, multiplexing a single public IP address for multiple private IP nodes isn't possible.
IPv6 does away with NAT (at least officially) and hopefully we're going to see some smart future development in this area.