41–48 of 48 posts
1) It makes the SCTP header complex. Without it, IP address in IP header is sufficient. With it, IP addresses have to appear in SCTP header too.
2) Multi-homing makes it difficult to configure firewall rules, for example NAT(Network Address Translation). Linux tools like iptables, LVS(Linux Virtual Server) do not work well with it.
3) I think the benefit of multi-homing can be gained in Network-layer or Data-Link layer instead of transport layer, for example network interface bonding, etc. It relieves the complexity of the application in this way.
I must iterate:" I’m taking a 3000-foot perspective here, it is still a far away perspective although less a 0 than the author, and whatever I’m writing could be completely wrong. If that’s the case, please point out my mistakes in your comments."
Has anyone implemented multihoming IPv6 capable of creating a continuous SSH session when switching networks?
Earlier quoted context omitted.
I think I can credibly defend an argument that what went wrong with SCTP was that it got an IP protocol number rather than a UDP port. That one decision meant that, on most operating systems, using the protocol would require a kernel change, and virtually no middlebox would pass SCTP frames unmolested. They saved eight bytes and some negligible amount of checksum processing, and got no other benefits from being a fir…
There's a spec for SCTP over UDP and libraries that implement it, so what's stopping anybody now?
But then there are some people who might be more interested in making a secure protocol from scratch (rejecting the layering complexity and third-party dependence of SSL). For instance: http://cr.yp.to/tcpip/minimalt-20130522.pdf
Earlier quoted context omitted.
It's a problem that apps have, but they just shift it onto the user.
That's a bit hard for me to fathom, because the overwhelming vast majority of users don't have multiple Internet connections, and serverside applications can make use of multiple Internet connections without protocol-level multihoming.
" However, by far the biggest showstopper to SCTP adoption is the lack of session layer in TCP/IP and the broken Socket API. If you want to use SCTP with the Socket API, you have to indicate the protocol to use in the socket call, which means that every application that would benefit from SCTP support must be changed, recompiled and tested. There is no way that you could take existing applications, add SCTP support i…
I think I can credibly defend an argument that what went wrong with SCTP was that it got an IP protocol number rather than a UDP port. That one decision meant that, on most operating systems, using the protocol would require a kernel change, and virtually no middlebox would pass SCTP frames unmolested. They saved eight bytes and some negligible amount of checksum processing, and got no other benefits from being a fir…
Earlier quoted context omitted.
I think I can credibly defend an argument that what went wrong with SCTP was that it got an IP protocol number rather than a UDP port. That one decision meant that, on most operating systems, using the protocol would require a kernel change, and virtually no middlebox would pass SCTP frames unmolested. They saved eight bytes and some negligible amount of checksum processing, and got no other benefits from being a fir…
You are possibly right, although I suspect the kernel change issue is less of a problem than the second. Getting middleboxes to pass UDP unmolested....
Earlier quoted context omitted.
You might be able to credibly defend it, but it's still depressingly silly that we're cut off from a large swath of our extensible-by-design protocol stack. These days, people justify HTTP for everything with the argument that opening up a TCP socket is not guaranteed to work as reliably as HTTP-over-TCP. They might be right, but god that sucks.
I see arguments like this as a form of the naturalist fallacy. Not every aspect of the original TCP/IP design is worth preserving and exploiting. We don't need an URG pointer. We don't need IP source routing (really, we don't need the IP options we have now). We don't need a "length" field in UDP. &c. TCP should have been built on top of UDP, as should ICMP. The IP "protocol" field doesn't do us much good. I don't th…