4 ms·
you can run a new protocol on top of IP "relatively" easily: it routes fine across the internet as switches and routers don't care about TCP[1] (switches don't
by blibble 4y ago
you can run a new protocol on top of IP "relatively" easily: it routes fine across the internet as switches and routers don't care about TCP[1] (switches don't even care about IP)
linux will even let you do it from userspace (with net_admin cap)
there are some exceptions: like if your endpoint is some a crappy cloud provider (e.g. azure) that provides you something that looks like an ethernet network but really is a glorified TCP/unicast UDP proxy
[1]: ignoring NAT and IGMP/MLD snooping (not that anyone does those outside of internal networks... right?)
- xxpor 4y agorouters care about tcp (or udp) because of flow hashing. write a new IP proto and see what happens when you try to push >100 gbit
- blibble 4y agoyou have 3 out of 5 parts of the standard tuple not perfect but not unworkable either
- toast0 4y agoIt can be necessary to get flow hashing on high volume server A : server B communications (especially if you're running aggregated interfaces and are using multiple connections). If you need that in a 3-tuple hashing environment, you're going to need to apply many addresses to one or both servers, which is going to cause problems with arp/ndp cache sizes. Maybe that's ok if you just route a /64 to each server and don't use NDP inside the /64; but you probably need to work on the server OS to work with many addresses well, things get a little shifty there.
- pezezin 4y agoIsn't that why IPv6 includes an explicit flow label in the header?