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.'"
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.
You need to run the article through a ROT13 filter, followed by the Bible Code decoder and finally the Redneck filter, to get the URL of the real article. This encryption technique was developed to prevent the real server being slashdotted.
Pricing complexities are why multicast is taking so long to reach the home, even though it has been enabled clear across the entire backbone up to the local ISP level for over a decade. The virtual circuits costing issue is presumably part of why MPLS is also somewhat of a rarity. Of course, this does raise some questions, one of which is why - when the early Internet and IPSS were Government-funded, mostly Government-run, intended to be fault-tolerent and suitable for military use - cost was a factor at all. Big business did not enter the X.25 or TCP/IP markets until very late in the game, and most initially used gateways off their own internal network protocol. The Internet's native protocols should have had no impact at that time.
So why is it normal for the immaterial to matter more than the significant? It is normal, but it is also irrational and nonsensical.
I guess this moderator thinks that 'troll' means "I didn't understand a word you just said".
No no no! Didn't you get the memo? For the time being Moderators are to use Overrated, Flamebate, and Troll until the new options of -1 Unpopular, -1 Shut-up, and -1 I-just-don't-like-you are rolled out. It's just a workaround, so be patient.
Any ISP that uses RIPv2, OSPFv3 or ISIS on their internal network - or to connect to other networks - uses multicast for the routing protocol. Core providers broadcasting multicast services that are visible to AmericaFree.tv are listed in table format [multicasttech.com]. It's longer than two entries. Translations of BGP entries to providers are . Local ISPs that actually provide multicast to the home are a rarity, but as of 2002, there are a handful [multicast-isp-list.com].
I never said anything about nuclear war, I specified fault tolerence. There
Any ISP that uses RIPv2, OSPFv3 or ISIS on their internal network - or to connect to other networks - uses multicast for the routing protocol.
True, but irrelevant in considering whether a customer might one day get IP multicast on an ISP connection. The routing protocols you mention (and OSPFv2 as well) use multicast packets with TTL=1 to exchange information across a LAN. Not at all the same thing - no multicast forwarding tree in sight!
as of 2002.
Which says everything you need to know about interdomai
Customers are almost certain never to get IP Multicast, but (probably) not for technological reasons. It's easy to bill per stream, for unicast streams, but harder for multicast. And, let's face it, there are certain segments of the entertainment industry - not just the *AA's - that have a vested interest in providing heavily metered audio/video streams. Multicasting has the potential to slash revenue by an order or two of magnitude. It's also easier to guague interest (for advertising reasons) for unicast connections than for multicast. And since unicast demands more on the CPU and on the pipe, machine manufacturers and ISPs have financial incentives to encourage customers to use the least-efficient delivery format possible.
If the customers are the only ones who could gain, and everyone else would lose, then who is going to be insane enough to switch on multicast routing to the home?
The benefit of multicast is to the network provider. Where the same stream needs to be sent to many (thousands) of customers, multicast has a huge benefit. In fact, for 'push' content delivery it is the only viable means of networking.
And cable has been able to deal with the pricing issues for decades. The content is encrypted, with multiple keys---one for each subscriber. Anyone else can receive the multicast, but it does them no good without the key. When you join the stream, you not only join at an IP le
I guess you are correct, but then we get back to the problem of why this option doesn't currently exist for consumers. Hang on, I think my brain is going to explode.
If you're using MPLS on a WAN, I'm scared. MPLS is for extranets, the WAN is concealed. MPLS on a WAN is therefore a contradiction in terms. Either you're dealing with a WAN or you are dealing with an extranet. You are never dealing with both at the same time. You are almost never dealing with MPLS at the enterprise-level, because that level of detail is normally hidden. You have an entry point onto the extranet, but how that extranet is formed is transparent.
You may have a lot of experience, but I think you're generalizing your ATM vs. MPLS argument from the perspective of a small business. A lot of companies, including mine, have moved to MPLS for their WAN. (And, I don't miss the ATM days at all.)
Of course, our revenue is about the same as Microsoft, so I'm talking about a very large network (70+ large international manufacturing sites, multiple data centers, 10-20k users).
In case anyone wants to know. Let's have some calculations, shall we ? IF we were to bring multicast (like people here want, random senders, random receivers) to the home, we'd need the following resources in the router's memory. -> A place to put a multicast address (that'd be 4 bytes for ipv4, 16 bytes for ipv6) -> A place to put, associated with each multicast address, a series of interfaces to replicate the traffic to (that'd be a bit per interface in the router and per multicast address) (let's say
You only need an address for each group address subscribed to by a downstream node. Since you have access to port numbers, you can place as many streams on a single address as you like (up to 65535), although obviously you lose some benefit from the multicasting if you overload too many streams onto a single group address. Well, unless you use source-specific multicast (SSM), in which case so long as the content is differentiated by source address, you can stuff everything onto a single group if you really
Maybe he does. I've not seen 3Com for a while and Bay went belly-up. If he was the chief designer for those two, it would explain what happened to them.
The virtual circuits costing issue is presumably part of why MPLS is also somewhat of a rarity.
Is MPLS that much of a rarity? Business point-to-point or point-to-multipoint lines around here tend to be delivered either by MPLS or 802.1ah. Most MPLS-based lines are generally more expensive than raw Internet lines, but that's simply because MPLS is awfully expensive per VRF, so providers don't like having lots of VRF's.
(Of course it's also possible to do virtual routing without MPLS. That's how I make a livin
Unfortunately, for all of us, IPv6 is heading our way like some rusty old stream train. Its rickety and badly designed, but massive, and will squash anything in the way. IPv4 at least was designed well, and has lasted a long time. However, IPv6 has no firewall/NAT support (if you are in a company, you have to have a firewall, else you run afoul of a lot of corporate regs like SOX, HIPAA, and if doing credit cards, PCI). You can't tunnel or VPN (if you do, you pretty much do IPv4 routing as a kludge.) Fin
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.
I personally believe it will never be adopted. The government keeps having meetings where they set dates for implementation, that get turned into dates to have implementation plans. Meanwhile the clock is ticking and its ten years later. The internet has changed from when they drafted IPv6, who is going to make thier customers flash thier home routers? Time to punt and send folks back to committee. It is just as crufty as the OSI network stack. If they had just gone with the first draft and added more addres
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.
"if you change ISPs or peers, you have to completely re-IP your servers" I missed that the first time. Sounds like we got another IPv6-slam in TFA.
And this is different than IPv4 how? In the US, this is the norm. I know, my dear friends that manage my access like to change ISPs about 4 times more often than they change cell phone providers. And for even dumber reasons. They don't even geta free CSU/DSU most of the time, and of course the new provider needs us to use 'theirs', so they can manage it. And
My first response to this was, "Say what"? But I did a little Googling and it seems you're quite correct. I'm not as literate on IPv6 issues as I should be, but this strikes me as pretty dumb.
The main thesis of this argument seems to be that the primary purpose of NATs is to work around the IP address shortage, which IPv6 eliminates. But there's another big reason to want an IP address in a private space: security. Do you want every script kiddie on the planet bang
Huh? You can do exactly the same stuff with a firewall as you do with NAT. If you want to forbid all incoming connections by default, and only allow specific ones, you can do so very easily with a firewall.
The only difference is that with NAT you have one IP address, and port 80 (for example) either is directed to a specific computer on the network, or isn't.
In comparison, with IPv6, no NAT, and a firewall you'd be able to control whether each computer on the internal network accepts connections on port 80 o
Yeah, you can use an IPv6 firewall that blocks all incoming traffic except for replies to outgoing traffic and exceptions made for specific servers, and you have the same "firewall" protection as an IPv4 NAT with none of the protocol breakage caused by NAT. Two machines could use the same port without one or both getting changed by NAPT for example, and having the server's own IP be the same one that clients have to connect to helps as well.
There is no personal IP range, which is a darn good thing. Can you imagine the load that would put on routers, having a few billion routes changing constantly? However, with the "autoconfiguration" if I'm not mistaken, the last 64 bits of your IP would pretty much always stay the same, its the first bits that would change.
Besides, in a way your IP address will always be the same, and much shorter..::1 is much shorter than 127.0.0.1 to type!
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!
can be simplified quite a bit when you take out the various NAT-hole punch routines. Assuming people use statefull packet inspection firewalls with a "outbound and replies to outbound only" policy the hole punch routines will have to stay.
Assuming people use statefull packet inspection firewalls with a "outbound and replies to outbound only" policy the hole punch routines will have to stay.
Sure. But without network address translation, protocols like IPSEC will work end to end and proxies for inspecting and rewriting packet payload will not be necessary. UPNP will no doubt still be used (and a serious security risk) for punching holes in the firewall but at least the few-to-many address mapping problem which breaks many protocols will be g
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.
A very significant factor for the slow uptake of TCP/IP was that most early networks were slow and point-to-point (head office to branches for realtime links and uucp etc for emial). IP wrapping is relatively expensive in terms of extra bytes etc, but that wrapping gives flexibility. When you only had 1200 baud point-to-point connections then you didn't need the flexibility of IP nor the extra wrapping cost.
IP only started to shine once significant numbers of networks got interconnected.
WANs, yes. LANs based on 10MBit Ethernet was fairly popular -- but most of them ran proprietary protocols like IBM's NetBIOS and, later, Novell's IPX/SPX.
And anyway, by your logic X/Y/Zmodem wouldn't have existed because these protocols also wasted bandwidth. These were the basis of early store-and-forward networks like FidoNet.
Frame SVCs wore never in huge demand. As Vint says, customers wanted cheap leased line replacements, and the ability to do hub and spoke and mesh networks cheaply. What do SVCs buy you? you already have to pay for the local loop. Cheaper Virtual circuits? Eventually the market moved to zero cir pvcs, which were as cheap as you needed.
Besides, there were carrier SVC networks, the protocol was called SMDS, and no one bought it.
where's the content? (Score:5, Insightful)
A little more here... (Score:5, Informative)
Parent
Re:A little more here... (Score:4, Informative)
Parent
Re:A little more here... (Score:4, Funny)
Parent
Re: (Score:2)
Re:where's the content? (Score:5, Funny)
Parent
The Da Vinci Codec (Score:1, Funny)
Which, of course, explains why it took so long to get implemented.
Re: (Score:2, Funny)
It's split up. One packet went to Australia, another to Zimbabwe, and another to
United States of America's Government Conspiracy (Score:2)
Re: (Score:2)
Seems normal. (Score:5, Interesting)
So why is it normal for the immaterial to matter more than the significant? It is normal, but it is also irrational and nonsensical.
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:2)
no (Score:1)
Please name the "Local ISPs" that have multicast configured. I count Two out of Five core providers with multicast enabled.
I wouldn't call MPLS somewhat of a rarity. Simply put I disagree entirely.
Re: (Score:2)
I never said anything about nuclear war, I specified fault tolerence. There
Argh! Typo! (Score:3, Informative)
Re: (Score:2)
True, but irrelevant in considering whether a customer might one day get IP multicast on an ISP connection. The routing protocols you mention (and OSPFv2 as well) use multicast packets with TTL=1 to exchange information across a LAN. Not at all the same thing - no multicast forwarding tree in sight!
Which says everything you need to know about interdomai
Re:no (Score:5, Insightful)
If the customers are the only ones who could gain, and everyone else would lose, then who is going to be insane enough to switch on multicast routing to the home?
Parent
Re: (Score:3, Insightful)
And cable has been able to deal with the pricing issues for decades. The content is encrypted, with multiple keys---one for each subscriber. Anyone else can receive the multicast, but it does them no good without the key. When you join the stream, you not only join at an IP le
Re: (Score:2)
Where's the beef? (Score:2)
Of course, none of this matters if you're not
Re: (Score:2)
Of course, our revenue is about the same as Microsoft, so I'm talking about a very large network (70+ large international manufacturing sites, multiple data centers, 10-20k users).
Re: (Score:1)
-> A place to put a multicast address (that'd be 4 bytes for ipv4, 16 bytes for ipv6)
-> A place to put, associated with each multicast address, a series of interfaces to replicate the traffic to (that'd be a bit per interface in the router and per multicast address) (let's say
Re: (Score:2)
Re: (Score:2)
I'm glad you don't design routers.
Re: (Score:3, Funny)
Re: (Score:2)
Is MPLS that much of a rarity? Business point-to-point or point-to-multipoint lines around here tend to be delivered either by MPLS or 802.1ah. Most MPLS-based lines are generally more expensive than raw Internet lines, but that's simply because MPLS is awfully expensive per VRF, so providers don't like having lots of VRF's.
(Of course it's also possible to do virtual routing without MPLS. That's how I make a livin
TCP/IP still needs a rewrite (Score:2, Interesting)
IPv4 at least was designed well, and has lasted a long time. However, IPv6 has no firewall/NAT support (if you are in a company, you have to have a firewall, else you run afoul of a lot of corporate regs like SOX, HIPAA, and if doing credit cards, PCI). You can't tunnel or VPN (if you do, you pretty much do IPv4 routing as a kludge.) Fin
Re: (Score:3, Informative)
Amen Brother. (Score:1)
Time to punt and send folks back to committee. It is just as crufty as the OSI network stack. If they had just gone with the first draft and added more addres
Re:TCP/IP still needs a rewrite (Score:4, Insightful)
Parent
Re:TCP/IP still needs a rewrite (Score:5, Informative)
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.
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.
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.
Parent
Re: (Score:2)
I missed that the first time. Sounds like we got another IPv6-slam in TFA.
And this is different than IPv4 how? In the US, this is the norm. I know, my dear friends that manage my access like to change ISPs about 4 times more often than they change cell phone providers. And for even dumber reasons. They don't even geta free CSU/DSU most of the time, and of course the new provider needs us to use 'theirs', so they can manage it. And
Goodbye NAT? (Score:2)
My first response to this was, "Say what"? But I did a little Googling and it seems you're quite correct. I'm not as literate on IPv6 issues as I should be, but this strikes me as pretty dumb.
The main thesis of this argument seems to be that the primary purpose of NATs is to work around the IP address shortage, which IPv6 eliminates. But there's another big reason to want an IP address in a private space: security. Do you want every script kiddie on the planet bang
Re: (Score:2)
You can do exactly the same stuff with a firewall as you do with NAT. If you want to forbid all incoming connections by default, and only allow specific ones, you can do so very easily with a firewall.
The only difference is that with NAT you have one IP address, and port 80 (for example) either is directed to a specific computer on the network, or isn't.
In comparison, with IPv6, no NAT, and a firewall you'd be able to control whether each computer on the internal network accepts connections on port 80 o
Re: (Score:2)
Re: (Score:2)
Besides, in a way your IP address will always be the same, and much shorter..
Re:TCP/IP still needs a rewrite (Score:5, Informative)
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!
Parent
Re: (Score:2)
Assuming people use statefull packet inspection firewalls with a "outbound and replies to outbound only" policy the hole punch routines will have to stay.
Re: (Score:2)
Sure. But without network address translation, protocols like IPSEC will work end to end and proxies for inspecting and rewriting packet payload will not be necessary. UPNP will no doubt still be used (and a serious security risk) for punching holes in the firewall but at least the few-to-many address mapping problem which breaks many protocols will be g
Re: (Score:3, Informative)
Historical analysis (Score:2)
Anyway, thank Gore we're not stuck in an X.25 world!
TCP/IP wastes bandwidth (Score:2)
IP only started to shine once significant numbers of networks got interconnected.
Re: (Score:1)
And anyway, by your logic X/Y/Zmodem wouldn't have existed because these protocols also wasted bandwidth. These were the basis of early store-and-forward networks like FidoNet.
PVC tubes (Score:2)
Best feature but no market? (Score:1)
Besides, there were carrier SVC networks, the protocol was called SMDS, and no one bought it.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)