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 workgroup 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. Twenty years ago 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”. 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 we’re already running out of IPv4 addresses.
Posts
Oh, and what about LISP+ALT / HIP ? :)
ReplyDeleteWhat about SCTP?
ReplyDeleteWhat about SCTP?
ReplyDeleteLISP will solve this...if it is adopted. It looks awesome and seems to be well thought out. I just heard one of the authors of it speak and I was impressed.
ReplyDeleteLISP will _NOT_ solve this particular problem. LISP tries to save the IP core from exploding. It addresses the consequences, not the root cause of the problem.
ReplyDeleteOnly used in telecom networks to connect servers that speak SS7 to each other. Sorry for being general SCTP is a transport for SS7 over IP instead of the legacy SS7 over TDM.
ReplyDeleteThat's the only place I've seen it used.
Oh, forgot to post the link to the SCTP post:
ReplyDeletehttp://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.
Actually I think LISP when it's implemented in the host stack could help "solve"[1] this problem. When the host is the xTR, like some in some of the mobile node examples, LISP ends up looking a lot like SHIM6 to me. The EIDs end up being session endpoint identifiers and since the EIDs themselves are IP addresses the applications can still use the Socket API. The nice thing about this is that there is a path of increment deployment - LISP could end up being implemented in network devices first and then migrate to being implemented in the hosts.
ReplyDelete(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 ;)