Why is the protocol field part of an IP header?

Question

Note this is not a duplicate of Why is the IP layer aware of higher layers in the network stack?

The need for a protocol identifier (eg. the IP header's Protocol field) in packet-based communication is clear: It's either this or some sort of computationally-intensive inference algorithm. The question is: why must it exist as part of the IP header rather than in the encapsulated protocols' headers?

It seems to me that this one of those cases where theoretical clarity meets practical considerations (AKA "Haskell meets Go"...): On the one hand placing a "protocol" field in the IP header breaks the conceptual separation of interests that eg. the OSI model aimed for; on the other hand forcing protocols higher up the stack to state their type in a consistent manner is much harder, and would eventually lead to a similar situation anyway (eg. if every protocol higher up the stack used its first header byte to state its type, it would look as if IP used its last header byte to do the same).

So my question is - what was the reasoning behind placing the "protocol" field inside the IP's packet header rather than anywhere else?

Edit: When writing this question I pondered whether to add the word "original" before "reasoning", ie the reasoning of the team that devised IP, but reckoned it was redundant as the question was phrased in the past tense ("what was the reasoning..."). Nevertheless this seems needed, as none of the replies actually answers that question. Some insights of note:

• @immibis suggests any other form would break other protocols' models (eg. encrypted communication protocols would have to have a plaintext identification field)
• @Eddie essentially states that the reason is convention (acceptance of the protocol chain design, though why that's the convention remains a mystery)
• @Ricky stresses practicality as an overarching consideration
• @Claudio suggests that were the protocol field a part of the encapsulated header there would be need for an additional header identification step, where in the current model that takes place during the IP header's parsing

So I'll rephrase: What's wrong with a model where instead of every header identifying the next header's type, every header identifies its own type in a predetermined location (eg. in the first header byte)? Why is such a model any less desirable than the current one?

Edit #2: It seems that the answer is a combination of several of the answers given (mainly those mentioned above along with @Eddie's second addendum):

1. Simplicity: Breaking the principal of layer agnosticism in this particular case means the stack (or the model) as a whole can be simpler:

   • There's no "protocol identification" phase, neither implicit nor explicit
   • Layer independence is improved (eg. an encrypted communications handler doesn't have to share a layer with any helper protocol)

   Regulation is also greatly simplified, not having to enforce any requirements on client protocols.

2. Performance: Stating the protocol of an encapsulated packet ahead of the packet itself allows several types of fast routing protocols (packet filtering, QOS, cut-through switching) to be integrated into the network (internet) layer itself; these can then make decisions as quickly as a hash table can be accessed, which is all the more important considering the limited hardware this protocol was designed to run on.

This model has its disadvantages, but it seems that for the common usage cases it's better suited than the alternatives.

Answer 1

Remember, bits arrive on a NIC as a series of 1's and 0's. Something has to exist to dictate how the next series of 1's and 0's should be interpreted.

Ethernet2 is the defacto standard for L2, as such it is assumed to interpret the first 56 bits as a Preamble, and the next 8 bits as the Preamble, and the next 48 bits as the Destination MAC, and the next 48 bits as the Source MAC, and so on and so forth.

The only variation might be the somewhat antiquated 802.3 L2 header, which predates the current Ethernet2 standard, but also included a SNAP header which served the same purpose. But, I digress.

The standard, Ethernet2 L2 header has a Type field, which tells the receiving node how to interpret the 1's and 0's that follow:

Without this, how would the receiving entity know whether the L3 header is IP, or IPv6? (or AppleTalk, or IPX, or IPv8, etc...)

The L3 header (to the same frame as above) has the Protocol field, which tells the receiving node how to interpret the next set of 1's and 0's that follow the IP header:

Again, without this, how would the receiving entity know to interpret those bits as an ICMP packet? It could also be TCP, or UDP, or GRE, or another IP header, or a plethora of others.

This creates a sort of protocol chain to indicate to the receiving entity how to interpret the next set of bits. Without this, the receiving end would have to use heuristics (or other similar strategy) to first identify the type of header, and then interpret and process the bits. Which would add significant overhead at each layer, and noticeable delay in packet processing.

At this point, its tempting to look at the TCP header or UDP header and point out that those headers don't have a Type or Protocol field... but recall, once TCP/UDP have interpreted the bits, it passes its payload to the application. Which undoubtedly probably has some sort of marker to at least identify the version of the L5+ protocol. For example, HTTP has a version number built into the HTTP requests: (1.0 vs 1.1).

---

Edit to speak to the original poster's edit:

What's wrong with a model where instead of every header identifying the next header's type, every header identifies its own type in a predetermined location (eg. in the first header byte)? Why is such a model any less desirable than the current one?

Before getting into my attempt at an answer, I think its worth noting that there is probably no definitive million dollar answer as to why one way is better or the other. In both cases, protocol identifying itself vs protocol identifying what it encapsulates, the receiving entity would be able to interpret the bits correctly.

That said, I think there are a few reasons why the protocol identifying the next header makes more sense:

#1

If the standard was for the first byte of every header to identify itself, this would be setting a standard across every protocol at every layer. Which means if only one byte is dedicated we could only ever have 256 protocols. Even if you dedicated two bytes, that caps you at 65536. Either way, it puts an arbitrary cap on the number of protocols that could be developed.

Whereas if one protocol was only responsible for interpreting the next, and even if only one byte was dedicated to each protocol identification field, at the very least you 'scale' that 256 maximum to each layer.

#2

Protocols which order their fields in such a way to allow receiving entities the option to only inspect the bare minimum to make a decision only exists if the next protocol field exists in the previous header.

Ethernet2 and "Cut-Through" switching come to mind. This would be impossible if the first (few) bytes were forced to be a protocol identification block.

#3

Lastly, I don't want to take credit, but I think @reirab's answer in the comment in the comments of the original question is extremely viable:

Because then it's effectively just the last byte of the IPv4 (or whatever lower-level protocol) header in all but name. It's a "chicken or egg" problem. You can't parse a header if you don't know what protocol it is.

_{Quoted with Reirab's permission}

Answer 2

You may as well ask why an ethernet header has an Ether Type field. The network stack needs to know which protocol in the next higher layer gets the payload of the current layer.

Edit 1:

The reason that each datagram has the protocol of the next upper layer is to create the layer independence. Each layer doesn't care what is in the payload, and it shouldn't need to look in the payload to determine where to deliver the payload. Think of the protocol number in the header as an address where the payload is to be delivered. Much like TCP port numbers are TCP addresses, they tell TCP where to deliver its payload.

The destination MAC address tells the network switch which switch interface to deliver the frame. The Ether Type field tells layer-2 where to deliver its payload, the Protocol field in the IP header tells layer-3 where to deliver its payload, and the port numbers in TCP and UDP tell layer-4 where to deliver its payload.

Think of an 18-wheeler truck driver who hooks up to a trailer to deliver it somewhere. He doesn't need to worry what's in the trailer, or for what it will be used; he just looks at his paperwork and delivers it to the place in the paperwork.

You need to remember that each of the protocols was developed independently without knowing which emerging upper-layer protocols would be used. For a long time, the primary layer-3 protocol used on ethernet was IPX. Had ethernet been created specifically for IPX, would it be so ubiquitous today? Ethernet was built to carry any layer-3 protocol by having the Ether Type field which the network stack can use to decide where the ethernet payload goes. IP does the same thing, and so do TCP and UDP. It is an easy and logical method which is why each independently-developed layer in the network stack has an equivalent. You, and anyone else interested, are free to develop your own protocol(s) for any of the layers which can easily plug into the network stack because of this.

Edit 2:

It allows different layer-3 protocols to register with layer-2. You can simultaneously run IPX (0x8137), IPv4, (0x0800), ARP (0x0806), IPv6 (0x86DD), etc. protocols, and layer-2 will know which protocols have registered with it and pass the payload to the appropriate layer-3 protocol without knowing anything about the payload (or drop any packets which don't have a registered protocol). You don't want to have to have to install a different layer-2 protocol for each combination of layer-3 protocols you have, and that would be required if the layer-2 protocol must know more about the layer-3 protocol(s) in order to be able to read the packet headers. Even IPv4 and IPv6 packet headers are quite different.

Here is an incomplete list of values for different layer-3 protocols which may register with layer-2.

Layer-4 protocols also register with various layer-3 protocols, and applications register with layer-4 protocols.

Your original question posited that the layers should be independent of each other, and this sort of thing actually promotes layer independence, rather than breaking it as you suggest. Layer-2 doesn't know that the payload is IPv4, it only knows that the ethertype is 0x0800, and it should pass the payload to the layer-3 protocol which has registered that ethertype.

Answer 3

Not a direct answer to your question, but:

On the one hand placing a "protocol" field in the IP header breaks the conceptual separation of interests that the OSI aimed for.

TCP/IP was developed without reference to the OSI model. While they share some commonalities, it was a separate development effort.

Answer 4

The simplest reason, is to help parsing when a packet is received.

If you know which protocol follow, you can develop stricter constraint. The only dynamic aspect in the IP packet is the size (the presence of IP options increase this size in multiple of four bytes).

In parsing phase, you can check ip header length, protocol. Then, in the low level packet validation, the packet data is read through a data struct (usually, icmp, tcp, udp headers) and with easy packet is validated.

Answer 5

Just read the title :

When the IP packet contain TCP data the protocol number field will have the value 6 in it, so the payload will be sent to the TCP stack, TCP would then use the port numbers to send the data to the correct application. The same is for UDP with protocol number 17.

Another way to look at the IP protocol number field is, if we didn't have this field in the IP packet header, IP would only be capable of carrying one type of data, while adding this field allowed the IP to carry multiple types of data differentiated by the protocol number, the same goes for TCP/UDP using TCP/UDP ports to serve multiple applications and Ethernet using the Ethertype, and so on.