What Went Wrong: TCP/IP Lacks a Session Layer
One of the biggest challenges facing the Internet core today is the explosion of the IP routing and forwarding tables, which is caused primarily by traffic engineering and multihoming requirements. Things were supposed to get better when IPv6 introduced strict hierarchical addressing (similar to the phone number addressing, where the first few digits always denote the country code).
Unfortunately, the hierarchical IPv6 addressing idea relied on incredible belief that the world will shape itself according to the wills of the IETF working group members. Not surprisingly, that didn’t happen and the hierarchical IPv6 addressing idea was quietly scrapped, giving us plenty more prefixes to play with when trying to pollute the global IPv6 routing tables.
If we take a step back and ask ourselves: “why do we need IP multihoming in the first place?” the answer is simple: because the client application (layer-7 entity) connects to the IP address (layer-3 entity) of the server. If we want to have persistent sessions, the server IP address must remain reachable – the headaches are caused by tight coupling across numerous protocol layers.
The session persistence, session restarts, checkpoints and the ability to connect to multiple L3 addresses to reach the same service are the jobs of the OSI session layer … only there is none in the TCP/IP protocol stack. In 1990s, the IP zealots were quick to point out that “if you know what you’re doing, four layers are enough, if you don’t, even seven layers won’t help you” when making fun of the OSI protocol stack. Guess who’s laughing now (although the laugh is somewhat bitter and utterly irrelevant).
The worst part of the story is that the IETF community had the chance to fix their design problems when they realized that IPv4 will have to be replaced by something else. Unfortunately, the only thing they could agree upon was to replace IPv4 addresses with longer IPv6 addresses while retaining the rest of the (then) 15-year old design. Some people realized years later that the whole approach is broken and tried to fix it with SHIM6, but it was too little done way too late. The SHIM6 protocols are still in drafts, there are no commercial implementations and in the meantime we already ran out of IPv4 addresses.
That's the only place I've seen it used.
http://blog.ioshints.info/2009/08/what-went-wrong-sctp.html
SCTP is commonly used in scenarios where it's important to have communication between more than a pair of IP addresses (multihoming scenarios) and where the path loss detection is critical. I know it's used between PIX/ASA firewalls, supposedly it's also used between media gateways.
(While using another slice of IP addresses to represent sessions endpoints does seem messy, I think this namespace does need to be enumerated out of something. I wonder what the proposal for this is in the Recursive Inter-Network Architcture (RINA)?).
[1] Of course I'm using the term solve very loosely. Anyone that's been tracking LISP knows there are a lot of unanswered questions ;)