Vint Cerf on Why TCP/IP Was So Long in Coming

whitehartstag writes "TCP/IP is 25 years old this year. Vint Cerf says there was a long development cycle for both TCP/IP and for X.25, and we'd have been using TCP/IP much sooner if TCP/IP had been more marketable. 'Over the years, we can come up with many examples both of where the best technology did (or did not) win and of how marketing has defined a service. For example, many of the "best" features of frame relay, such as the ability to use Switched Virtual Circuits (SVC) in addition to Permanent Virtual Circuits (PVC) were never widely marketed because the pricing was too complex. Rather, the PVC was a simple replacement for a leased line at a fraction of the cost with better performance.'"

A little more here...

[XanC]

Apparently the "article" is a response to a comment (the only comment, mind you) attached to this "article" [networkworld.com], which is similarly content-free.

Re:A little more here...

[Megaweapon]

Plus the submitter's name+link goes to the same site, so I'm guessing this is just more NetworkWorld clickbait for Slashdot.

Re:TCP/IP still needs a rewrite

[jd]

IPv6-over-IPv6 seems to work ok. Some of the earliest routing protocols provided firewalling and NATting within the routing protocol itself (Telebit's router provided superb NAT and Firewall capabilities as an integrated facility). Permanent addresses lead to fragmented heirarchies and exploding routing tables, which is a major problem with IPv4.

Re:TCP/IP still needs a rewrite

[gclef]

So much misunderstanding crammed into such a small post. I'm impressed.

However, IPv6 has no firewall/NAT support

IPv6 partisans strongly discourage NAT, but there is nothing in IPv6 that will prevent it. Firewalling is still possible in IPv6, and is assumed to continue.

You can't tunnel or VPN

Where in the world did you get that from? There are several tunneling protocols supported as standard in IPv6. 6-in-6, IPSec, GRE...take your pick.

Finally, it doesn't support a person having their own permanent IP range. You are forced to use a subset of the range of whomever you are connecting to, and if you change ISPs or peers, you have to completely re-IP your servers.

This is untrue. ARIN (and most other RIRs) changed their allocation policy a year and a half ago. At present, if you qualify for Provider-Independent space in IPv4, you will also qualify for PI-space in IPv6.

Re:TCP/IP still needs a rewrite

[TheBracket]

A lot of your "missing" features of IPv6 are exactly what it was meant to eliminate! You absolutely can firewall IPv6 (just as you can firewall a regular routed IPv4 space; a default stateful "outbound only" IPv6 firewall is every bit as secure as a similar IPv4/NAT setup). OpenBSD's pf has supported firewalling IPv6 for years; I'm pretty sure ipfw on FreeBSD has it, too. Iptables on Linux also seems to support it.

NAT isn't something to be missed. The number of nasty kludges required to get protocols that require two peers each behind a NAT to communicate is ridiculous, and a lot of protocols (VOIP, P2P, most games, etc.) can be simplified quite a bit when you take out the various NAT-hole punch routines.

Juniper already ship IPv6 capable VPN kit, you can do it on various open source platforms with things like tinc, and Windows Server 2008 supports it.

In other words, IPv6 is taking a long time, but it's getting there - and support for essential features is developing decently well. I'd recommend getting familiar with it now; even if it never materializes in its current form, it's a good idea to play with lots of different setups and be ready for anything!

Argh! Typo!

[jd]

The translation list is here [multicasttech.com].

Re:TCP/IP still needs a rewrite

[Watson Ladd]

You are just wrong half the time, and half wrong all the time. First off, a firewall is a piece of software that prevents packets from getting through. It can work with IPv6 just fine. Tunneling and VPN is what IPSec is for in tunnel mode. IPv6 mandates IPSec support, so I don't see how that is a kludge. Finally the mobility of IP addresses across ISPs leads to exploding routing tables. It's just not an option.