0

I want do develop an IP based protocol oriented to smallest possible data overhead. For example UDP adds overhead of 8 bytes header. I want zero header.

I will use this protocol via 2G mobile network where every byte is paid. For example 8 bytes every second makes 252.288MB per year. With 0.1 Euro per MB that's ~25 euro per year. I don't want to pay for UDP header :)

According to list of IP protocol numbers, which one should I use so that I don't have problems with NAT or firewalls?

user1576055
  • 111
  • 2
  • You should use one of the "unassigned" ones, but as per the comment it's possible that nothing other than TCP or UDP will be allowed to work. – pjc50 Apr 21 '23 at 15:17
  • This sounds like a case of premature optimization. You are making a lot of assumptions about how mobile carriers measure data usage. Even if the European Union has defined requirements, not all countries or jurisdictions have. The carriers could be counting bits differently in each country -- or worse yet -- each carrier counts bits differently in every country. – Greg Burghardt Apr 21 '23 at 15:46
  • I'm not making assumptions, I know how my mobile carrier measures. He counts every byte pushed through PPPoS. – user1576055 Apr 21 '23 at 16:22
  • How much do you gain by compressing your data stream? Web sockets may be an option then. – Thorbjørn Ravn Andersen Apr 21 '23 at 17:24
  • Problem is that I want to transmit every second to have a real time data. It will be a few bytes, so compression doesn't help much. – user1576055 Apr 21 '23 at 21:52

2 Answers2

5

To work on a network with a NAT you must use a protocol the NAT supports. Usually that means TCP or UDP. Period. And you cannot just copy the protocol number. You have to actually use the protocol.

However, if you know which network the protocol must work on, you can see if its NAT supports other protocols. If you are buying a lot of SIM cards, you can ask the network provider to install a server inside their network, for a fee, and bypass the NAT. If you are buying a lot of SIM cards and your network usage is predictable, you can also ask them for a customized billing plan tailored to your needs.

user253751
  • 4,864
  • 3
  • 20
  • 27
  • 1
    this is an important rule in business: if you are spending a million dollars, the manufacturer can afford to have a meeting with you and then manufacture precisely what you need, and that is better for both you and them. Conversely, if you are only spending $10 then the meeting literally isn't worth the time for you or for them. – user253751 Apr 21 '23 at 15:06
  • I've accepted your answer, because of the NAT. But ICMP is also supported by NAT. So there may be more of them. – user1576055 Apr 21 '23 at 15:53
  • @user1576055 the point stands: it has to be something the NAT supports. And the NAT decodes ICMP packets by looking at the embedded UDP or TCP packet, anyway. (When a packet causes a problem and an ICMP packet is sent out, that ICMP packet includes the headers of the packet that caused the problem) – user253751 Apr 21 '23 at 17:57
  • Well for ICMP ping there is no UDP or TCP packet. I will quote from another thread "For ICMP query/reply type messages like Echoes (pings), NAPT uses the ICMP Query ID (sometimes just called the ICMP ID) the same way it would use a TCP or UDP port number." – user1576055 Apr 21 '23 at 21:50
  • @user1576055 still the NAT has to know all the protocols you use, including ICMP Ping – user253751 May 16 '23 at 21:27
2

The first thing you should do is take a step back and learn more about network topology so you can understand what those protocols do and what type of information is being stored in that header b/c without it? Your data is going nowhere, especially with UDP, much less any custom protocol you attempt to design.

When your device sends a packet of data, that packet is going to be handled by any number of devices between you and the final destination and none of those devices really knows anything about you, your intentions, the data, etc.. So there needs to be some way to tell each device in that chain how to handle your packet and where it should be going next. And what do you know: turns out, that's kinda what the UDP header is there for! Pretty important 8 bytes I think. So while you may feel like those 8 bytes are wasted space, the reality is, they're essential to getting your data where it needs to go.

Lastly, any new protocol you design, has to be something that every device between you and your destination, can understand. And now you're talking about adoption and implementation. It's not an easy job to design new protocols.

incongruentDoughnut
  • 371
  • 4
  • 1
    Actually, knowing where the packet is going next is what the IP header is for. The UDP header is for the final destination. – user253751 Apr 21 '23 at 15:22
  • Your answer doesn't help much. I know exactly what those 8 bytes do and I don't need them. Problem is NAT as user253751 mentioned. – user1576055 Apr 21 '23 at 15:58
  • You might not think you do, but devices handling your packets do, even if it's only at 'the last mile'. The IP protocol encapsulates data which may encapsulate data. A receiving device is going to use that IP proto number to determine _how_ it should unwrap any data inside. So if you chose, for example, #84 (TTP), then the receiving device is going to try to handle the content according to the TTP specification which isn't going to help you much. To override that behavior, you'd need to re-write the driver for your network device to change how it handled just that specific protocol. – incongruentDoughnut Apr 21 '23 at 17:15
  • @incongruentDoughnut the UDP header is meant to be handled by the sending device and the receiving device. If you control both, then you can put whatever you like in that space because nobody gives a shit except you. However, NAT (which is terrible) also handles it. – user253751 Apr 21 '23 at 18:02
  • @user253751 Yes, you can put whatever you want in there when you send it, but when it's unwrapped per the identifying protocol (17:UDP), it's still going to be pushed to the port indicated that header before your app can do anything to it. That delivery (to the port) happens at the transport layer (L4) and the only way you're going to change that is to re-write the drivers for your device to specifically handle UDP (or whatever proto you want to fake) differently. – incongruentDoughnut Apr 21 '23 at 18:22
  • @incongruentDoughnut you're talking about if you don't control the receiving device – user253751 Apr 21 '23 at 18:22
  • @user253751 What is the device you're referring to? If you're talking 'my pc' then you're ignoring the OSI model entirely. Everything up to Layer 4 is more or less managed by your network device, not the OS (bit of a grey area really). A receiving application has to bind to a port for it to receive any data and that binding requires naming the protocol it wants to speak. Packets don't just magically get delivered 'because'. – incongruentDoughnut Apr 21 '23 at 18:31
  • @incongruentDoughnut the OSI model is a model. Don't confuse the map for the territory. There is nothing stopping me from making a sending and receiving device that store arbitrary data in these 8 bytes, and they will communicate just fine over the internet (but not through a NAT) – user253751 Apr 21 '23 at 18:34
  • I agree that faking an existing protocol could potentially conflict with network drivers. I could modify the drivers as I control both endpoints. But that wasn't my intention. I wanted to have my own IP based protocol. We all know that to transmit IP packets only L1, L2, L3 are needed. Ports are related to L4, so I really don't need those 8 bytes to transmit an IP packet. But it seems that because of NAT I just can't send arbitrary IP packet :( – user1576055 Apr 21 '23 at 21:33