Perhaps a surprising number of these non-tcp-or-udp protocols are in common use, other than ICMP and ICMPv6, at least the following are relatively common: GRE (47), L2TP (115), IPv6 within ipv4 (41, probably less common nowadays but used as part of 6to4), igmp (2), ipsec (50,51 as mentioned), ospf (89).
Of these GRE, L2TP, ipsec and 6to4 should be reasonably usable over WAN. Generally issues will arise at the ends of the path, the middle usually doesn’t care that much.
Also of interest are protocols that sit atop ethernet, beside IP and IPv6: ARP, PPPoE
oh how could you forget GTP(C/U) pretty much responsible for all mobile data traffic that we have today.
Mobile networks remain somewhat of a mystery to me and I haven’t yet run into a good resource that covers how they work.
But are you sure these don’t use UDP or TCP? I don’t see them under the IP protocol registry, but both are in the “Service Name and Transport Protocol Port Number Registry” with ports 2123 and 2152 respectively for C and U.
But are you sure these don’t use UDP or TCP? I don’t see them under the IP protocol registry, but both are in the “Service Name and Transport Protocol Port Number Registry” with ports 2123 and 2152 respectively for C and U.
oh my bad ! yes, GTP uses UDP underneath. I stand corrected.
Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo.
What a fun writeup! This reminds me I’ve been wanting to try writing a service with SCTP.
FWW, to get around most of the NAT shenanigans it’d be interesting to try using IPv6. But, some CPE might still try to track the state of a “session” or “flow”.
I’ve had this lowkey obsession with SCTP since learning about it like 20 years ago. My dream at the time was to create some kind of tool for LAN parties that let people transfer game patches, etc. over multiple interfaces at a time when having more than one 100 Mbps NIC was easily achievable.
You likely already know this, but WebRTC allows negotiation of video, audio and/or data channels. The data channels are SCTP.
So using a WebRTC lib allows you to set up SCTP channels peer-to-peer (you need to provide a signalling/SDP exchange, but that is only at connection setup time).
If somebody is looking for a book on this topic I’d suggest the venerable “TCP/IP Illustrated” by Richard Stevens [0]. My college professor had high opinions of it. I learned from it how to send raw ethernet frames on the wire (2 layers below TCP & UDP).
It’s a shame it’s like this. It’s a little silly QUIC is UDP instead of its own IP type, but it’s not realistic to add new IP types to the public Internet. At least UDP is a pretty lightweight wrapper.
I tried this over a decade ago, and I found that my home router refused to NAT non-UDP/TCP traffic. Then there’s the issue with middleware boxes scrubbing unknown traffic that makes me think that the Internet is now ossified with UDP/TCP forever. Shame, because I would love to play around with SCTP.
You actually can! NAT support for SCTP has been in the draft stage for ages. I’ve worked on an implementation for that in the FreeBSD kernel years ago, but that won’t help you much, if your router doesn’t support it. FreeBSD and usersctp (sctp in user space) both support sctp on top of UDP which allows you to play around with it on the internet. Similar concept as what quic is doing.
Perhaps a surprising number of these non-tcp-or-udp protocols are in common use, other than ICMP and ICMPv6, at least the following are relatively common: GRE (47), L2TP (115), IPv6 within ipv4 (41, probably less common nowadays but used as part of 6to4), igmp (2), ipsec (50,51 as mentioned), ospf (89).
Of these GRE, L2TP, ipsec and 6to4 should be reasonably usable over WAN. Generally issues will arise at the ends of the path, the middle usually doesn’t care that much.
Also of interest are protocols that sit atop ethernet, beside IP and IPv6: ARP, PPPoE
Another one that runs directly over ethernet is IS-IS, one of those weird parts of the OSI stack that somehow survived.
oh how could you forget GTP(C/U) pretty much responsible for all mobile data traffic that we have today.
Mobile networks remain somewhat of a mystery to me and I haven’t yet run into a good resource that covers how they work. But are you sure these don’t use UDP or TCP? I don’t see them under the IP protocol registry, but both are in the “Service Name and Transport Protocol Port Number Registry” with ports 2123 and 2152 respectively for C and U.
oh my bad ! yes, GTP uses UDP underneath. I stand corrected.
I’ve had success at routing IL (40) over the public internet. I’d expect it wouldn’t get passed properly by consumer equipment though.
Fantastic write-up really, fun read!
True to the ethos of:
ROFL
I really like the spirit of this entire writeup. This kind of drive to satisfy curiosity is infectious!
I wonder if anyone can explain the first packet getting through to the digitalocean droplet. That is quite weird
Just guessing without knowing any details, but I suppose it could be some sort of stateful firewall filtering
What a fun writeup! This reminds me I’ve been wanting to try writing a service with SCTP.
FWW, to get around most of the NAT shenanigans it’d be interesting to try using IPv6. But, some CPE might still try to track the state of a “session” or “flow”.
I’ve had this lowkey obsession with SCTP since learning about it like 20 years ago. My dream at the time was to create some kind of tool for LAN parties that let people transfer game patches, etc. over multiple interfaces at a time when having more than one 100 Mbps NIC was easily achievable.
You likely already know this, but WebRTC allows negotiation of video, audio and/or data channels. The data channels are SCTP.
So using a WebRTC lib allows you to set up SCTP channels peer-to-peer (you need to provide a signalling/SDP exchange, but that is only at connection setup time).
I thought this was going to be about homa: https://homa-transport.atlassian.net/wiki/spaces/HOMA/overview
But I like what it was way more. I like a world where people do stuff like this.
If somebody is looking for a book on this topic I’d suggest the venerable “TCP/IP Illustrated” by Richard Stevens [0]. My college professor had high opinions of it. I learned from it how to send raw ethernet frames on the wire (2 layers below TCP & UDP).
[0] https://archive.org/details/TCPIPIllustratedVol.1TheProtocols1stEdition/mode/2up
It’s a shame it’s like this. It’s a little silly QUIC is UDP instead of its own IP type, but it’s not realistic to add new IP types to the public Internet. At least UDP is a pretty lightweight wrapper.
I tried this over a decade ago, and I found that my home router refused to NAT non-UDP/TCP traffic. Then there’s the issue with middleware boxes scrubbing unknown traffic that makes me think that the Internet is now ossified with UDP/TCP forever. Shame, because I would love to play around with SCTP.
You actually can! NAT support for SCTP has been in the draft stage for ages. I’ve worked on an implementation for that in the FreeBSD kernel years ago, but that won’t help you much, if your router doesn’t support it. FreeBSD and usersctp (sctp in user space) both support sctp on top of UDP which allows you to play around with it on the internet. Similar concept as what quic is doing.
Nifty experiment!