As I mentioned when someone brought up the history of UDP, the original idea was that datagram protocols would be implemented at the IP level, as seen here. UDP offers the same functionality, but one level higher. In BSD, it was easier to do things from user space at the UDP level rather than at the IP level, and adding new protocols directly above IP fell out of favor.
Try to get an IP packet that's not TCP, UDP, or ICMP through a consumer level Internet provider.
I've never had much difficulty with ESP (protocol 50), 6in4 (Protocol 41), or GRE (protocol 47). By and large, if it's IP, your packet will get to the destination without too much filtering in North America with most of the major ISPs (Comcast, AT&T, etc...)
As someone who just set up IPv6 tunnels to both home and the office, I had no issues with 6in4 (proto-41) traffic with both ISPs I used. This is in The Netherlands.
I just confirmed that I can route a raw IP packet from my home connection to my server, by way of my ISP and hosting provider.
On the server, I ran "socat IP4-RECV:254 STDOUT", and on the client I ran "socat STDIN IP4-SENDTO:theservername:254", then typed at the client. Came through just fine.
To clarify Animats' point about getting non-TCP/UDP/ICMP packets through, it should probably be pointed out that it is difficult at scale. Yes, you may be able to send it from your network-aware workplace straight to your home computer, but if you release an some network product, an IM server/client perhaps, and switch it after a couple of years and some solid succuss to use SCTP only, you better bulk up your tech support staff first....
If nothing else, UDP provides ports, so multiple applications can be sending and receiving UDP datagrams at once without getting confused, or, indeed, even being aware of each other.
Comments
As I mentioned when someone brought up the history of UDP, the original idea was that datagram protocols would be implemented at the IP level, as seen here. UDP offers the same functionality, but one level higher. In BSD, it was easier to do things from user space at the UDP level rather than at the IP level, and adding new protocols directly above IP fell out of favor.
Try to get an IP packet that's not TCP, UDP, or ICMP through a consumer level Internet provider.
I've never had much difficulty with ESP (protocol 50), 6in4 (Protocol 41), or GRE (protocol 47). By and large, if it's IP, your packet will get to the destination without too much filtering in North America with most of the major ISPs (Comcast, AT&T, etc...)
I can't speak for other countries.
GRE tends to bugger off down a hole in a lot of ISPs in the UK from experience. Very annoying.
Is that a routing issue, or a fragmentation problem? Reducing your MTU on a GRE link greatly improves performance.
I'd be interested in hearing if there were any ISPs that didn't just forward GRE packets using normal IP routing conventions.
Absolutely no idea. AFAIK they just disappear into a void.
Used to be like this on Demon, Virgin Media and Easynet. The latter fixed their stuff circa 2007 however.
As someone who just set up IPv6 tunnels to both home and the office, I had no issues with 6in4 (proto-41) traffic with both ISPs I used. This is in The Netherlands.
I just confirmed that I can route a raw IP packet from my home connection to my server, by way of my ISP and hosting provider.
On the server, I ran "socat IP4-RECV:254 STDOUT", and on the client I ran "socat STDIN IP4-SENDTO:theservername:254", then typed at the client. Came through just fine.
Same here (Portuguese consumer level ISP).
To clarify Animats' point about getting non-TCP/UDP/ICMP packets through, it should probably be pointed out that it is difficult at scale. Yes, you may be able to send it from your network-aware workplace straight to your home computer, but if you release an some network product, an IM server/client perhaps, and switch it after a couple of years and some solid succuss to use SCTP only, you better bulk up your tech support staff first....
If nothing else, UDP provides ports, so multiple applications can be sending and receiving UDP datagrams at once without getting confused, or, indeed, even being aware of each other.
UDP is very heavily used in many areas.Certainly nothing wrong with it