Build the Next-Generation Data Center
6 week online course starting in spring 2017

Can we go back to CLNP?

Paulie, a frustrated enterprise IPv6 early adopter summarized his pains in a comment to my “Small-site multihoming in IPv6: mission impossible?” post saying “[IPv6/IPv6 support] is a mess and depressing” and asked “Is it too late to go to CLNS?”

Quite a few old-timers (I’m definitely one of them) lament the glory days of VMS, DECnet Phase V and CLNP, but while CLNP was a viable alternative for the next-generation IP in 1993, it would fare worse than IPv6 today.

The reason is very simple: IPv4 has evolved significantly in the last 15 years. It got all the nifty features that supposedly made IPv6 a better protocol (IPsec, QoS, autoconfiguration). There are also several decades of operational experience and gradual improvements that allowed us to build large-scale reasonably-manageable somewhat-secure networks.

IPv6 was definitely a better protocol than IPv4 in 1995, but then it got shelved for 15 years and while everyone was improving IPv4, nobody ported those improvements to IPv6 ... until we woke up, realized we had only a year or two left until IPocalypse and started dusting the by-now arcane protocol that barely anyone touched for more than a decade.

In the meantime, we also forgot what it means to be multiprotocol. The networking old-timers still have a vague remembrance of times when routers forwarded more than just IP packets, but the application programmers never had to think in multiprotocol terms. Have you ever seen an application that was able to run across IP and DECnet or across IPX and IP ... concurrently? The too-low-level socket API and lack of session layer (I’m mentioning both of them in my Upcoming Internet Challenges webinar) don’t help promote the multiprotocol deployment either.

The imminent (this time unavoidable) IPv4 address shortage has finally forced practically-minded and operations-focused people to start addressing IPv6 shortcomings and although the solutions are late, they are appearing. For example, DNS configuration is now standardized as part of IPv6 autoconfiguration mechanism. It’s true that it took more than a decade till everyone agreed configuring host parameters might also include configuring the DNS server address, but at least we’re making progress.

I doubt anyone touched CLNP recently (at least I haven’t seen many features appearing in Cisco IOS) and while it was a stable protocol 15 years ago (and still is), it lacks more features than IPv6 does. CLNP host implementations are also rare; IPv6 is ubiquitous in modern operating systems (apparently including iOS). Going back to CLNP is thus no longer an option.


  1. Architecturally, indeed, OSI protocol stack was more scalable than IPv4 back in 90s. Well, they didn't make the right choice then. It's too late to change the history now: all "better" IPng proposals such as TUBA, Nimrod etc have been rejected and rather boring SIP (IPv6) has been selected for "adoption". Security? QoS? Scalability? LOL. Nothing really differs IPv6 from IPv4 besides the larger addressing space. Which, in turn, may be the serious problem for routing systems.

    In fact, the Internet below the application level is the same it was almost 30 years ago, just stretched to match the applications that have been deployed. There have been NO architectural innovations since those old days. Sad, but we have to support the huge and pretty inflexible complex of technologies, praying that Moore law would give us enough time invent yet another band aid solution :(

  2. Thanks for the blog post Ivan. I'm an old timer too, but the transition from IPX/SPX to dual stack TCP/IP with LANworkplace for DOS I recall was easier than going IPv4 to IPv6. And that's a bit insane... :-). Thanks!

  3. Well, there are at least five differences between the migrations we did then and IPv4-to-IPv6 one:

    * We were late entrants, not early adopters. Although the TCP/IP stacks on DOS were awful (we were selling FTP Software and had "interesting" support issues), at least TCP/IP protocol suite was stable.
    * We were usually not running the same application over both stacks concurrently.
    * Most applications were not mission-critical, so we were not concerned about redundancy, dual-homing, fail-over ...
    * Users (and ourselves) were not spoiled. Believe it or not, IPv4 has raised the bar significantly in the last decades.
    * We were younger ;)


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.