Raw IP communication?

Question

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) ?

@MikePennington , ntp - network time protocol?,, well if I will not use any transport layer protocol then how can I send packets generated at network layer?? — lazarus, Jan 17 '15 at 03:50
You did not forbid transport layer protocols in your question; you only said "without passing through TCP protocols". Furthermore, if you think for a moment about how UDP and ICMP are constructed (on top of IP packets), it should be obvious that "yes you can build your own protocols inside of IP payload if you want". Very few people *should* want to — Mike Pennington, Jan 17 '15 at 05:13
UDP is a pretty thin layer upon IP (and has the same ordering and reliability guarantees which is: none) - basically all UDP adds is src and dst port, length, and checksum. Ports are useful if you expect more than one process on a system to be using your custom protocol at once. So you might as well use UDP in most real-world cases. — LawrenceC, Aug 16 '21 at 15:50

score 14 · Answer 1 · edited Oct 07 '21 at 06:47

[summarizing the question]

Can I communicate with raw IP datagrams, without a transport layer?

Short answer:

Yes, but:

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.

Longer answer:

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 people~~ everybody 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.

It's wrong to say that these are "exceptionally strange" things. See [this link](http://stackoverflow.com/questions/15702601/kernel-bypass-for-udp-and-tcp-on-linux-what-does-it-involve#comment61936819_15702601) for some of the many example use cases. Also, "*[the problem with TCP is simple: it was designed for fixed line environments, which are already in the minority in terms of client connections](http://www.theregister.co.uk/2015/09/08/tcp_more_than_30_years_old_and_it_still_holds_traps_for_the_unwary/)*" — Pacerier, May 13 '16 at 06:12
And "[*application context switching constitutes about 40% of the network overhead. So, it would seem that to improve bandwidth and latency of an interconnect, it would be good to eliminate the context switching*](http://ttthebear.blogspot.sg/2008/07/linux-kernel-bypass-and-performance.html)". — Pacerier, May 13 '16 at 06:39

user1301428 · Accepted Answer · 2015-01-18T12:14:22.187

8

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.

edited Jan 18 '15 at 12:14

answered Jan 18 '15 at 10:38

user1301428

356
1
5

2

That last statement is not strictly true I think, TCP could potentially use another layer 3 protocol. There is a discussion (not entirely serious) here: http://superuser.com/questions/449703/must-tcp-use-ip – Acyclic Tau Jan 18 '15 at 11:53
@AcyclicTau That is why I specified "in the OSI model" :) Let me clarify then, I understand where the confusion might come from. – user1301428 Jan 18 '15 at 12:07
If TCP segments get encapsulated by IP, and the segments from TCP always go through the IP layer, how come we talk about TCP offering unreliable datagram service ? Since it will be encapsulated by IP afterwards. – lukas irides Jan 18 '15 at 17:43
@lukasirides I think you are talking about UDP now. UDP is another Layer 4 protocol which, unlike TCP, does not guarantee delivery or offer error recovery (but is, consequently, faster). In fact, UDP stands for User Datagram Protocol. – user1301428 Jan 18 '15 at 17:50
No, i think that I was not precise enough. I mean that if I'm using TCP in the transport layer( and not UDP), and TCP is said to provide a reliable service. Furthermore, data from the transport layer will have to go through the network layer(using IP protocol), and IP uses datagram service which is unreliable. So at the end, how will the transfer be ? – lukas irides Jan 18 '15 at 18:12
@lukasirides then the transfer will be reliable. Remember, it's TCP who offers this service, IP only routes the packet for TCP. When the destination receives the packet, it will deencapsulate it and check the TCP header which contains, among other things, the sequence numbers, so it can check whether all packets have been received or not. If they haven't, the destination can request for the missing packets to be sent again. Does this make things clearer? – user1301428 Jan 18 '15 at 18:19
Now that fills the small gap I had and clears it all! thanks ! – lukas irides Jan 18 '15 at 18:25
@lukasirides Anytime ;) – user1301428 Jan 18 '15 at 18:29

score 4 · Answer 3 · answered Jan 17 '15 at 04:01

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.

score 4 · Answer 4 · edited Oct 07 '21 at 06:47

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. :)

score 2 · Answer 5 · answered Jul 24 '18 at 08:32

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 ("000019: %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 1.2.3.4?": 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.

score 0 · Answer 6 · answered Aug 13 '21 at 13:37

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.

Raw IP communication?

6 Answers6

Short answer:

Longer answer: