Slashdot Mirror
No Business Case For IPv6, Survey Finds
alphadogg writes "Business incentives are completely lacking today for upgrading to IPv6, the next generation Internet protocol, according to a survey of network operators conducted by the Internet Society (ISOC). In a new report, ISOC says that ISPs, enterprises and network equipment vendors report that there are 'no concrete business drivers for IPv6.' However, survey respondents said customer demand for IPv6 is on the rise and that they are planning or deploying IPv6 because they feel it is the next major development in the evolution of the Internet."
I for one would not be surprised to see China and the likes implement IPv6.
All those moments will be lost in time, like tears in rain. Time to die.
People ask what can IPv6 offer that NAT cannot. Try running multiple servers on multiple machines behind the same NAT, where one would like them to be accessible to the outside world via default port numbers. No amount of NAT configuration can get around this limitation, so saying NAT solves all the problems that IPv6 is supposed to answer is nothing more than self-delusional. Let's flip the question now.... what can NAT do that IPv6 cannot? Especially considering the fact that even *IF* for some reason that didn't involve how many IP's you actually have available, you still wanted to utilize NAT for some reason, you still could do that with ipv6... no problem at all. So what does NAT do that IPv6 can't? The only answer that might actually exist to this is that it arguably costs less to implement. So in reality, it's not that there's no business case of IPv6, it's really the case that these businesses are just cheap.
File under 'M' for 'Manic ranting'
IMO there is no question that when IPV4 addresses become scarce ISPs WILL push home users behind nat (with maybe an option to get a public IP address at a price high enough that only geeks pay it) to free up IP addresses for more lucrative customers.
I don't particularlly like NAT either but that doesn't mean it won't win out as the "soloution" to the IPV4 address shortage.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Speaking of NAT, how many wireless routers out there support ipv6? That might be the biggest hurdle.
It might be 3 years from now or perhaps even more but when ipv4 becomes scarce(and it will),
IPv4 addresses have been scare for a decade or so, the answer so far was to cripple the net with NAT or simply to raise prices when you want a real static IPv4 address instead of a dynamic one. I don't see that changing anytime soon. The problem is simply that IPv6 doesn't really provide any instant advantage, since hardly anything is available on IPv6 that isn't on IPv4. And the whole 'it will make networking simpler' isn't something the average user will grasp anytime soon, even worse, addding an IPv6 record to a webpage these days will break it for many people, because IPv6 routing is rather broken (i.e. you can get it easily via 6to4, but half the IPv6 webpages will not work with it).
Unless the government steps in and actually requires IPv6 for certain services I don't see anything changing. The most likely cause these days seems to be that China and other emerging markets go IPv6, while western world stays IPv4 for a while to come and then maybe slowly switch over to not end up disconnected to China and Co.
With 64 bit addresses that people can still scribble on a scrap of paper.
Part of the problem at the moment is that because network companies are failing to provide IPv6 ready equipment, it is only the dedicated few that are moving to IPv6. Linksys, D-Link I am talking about guys like you. The there are the ISPs like Bell and Telus here in Canada who have to plans, or even anything beta.
Now look in Africa, Asia and Europe and you will see some serious movement in that direction.
Don't get me wrong, I have my computer enabled with Tiredo, providing me IPv6 access, but companies are going to want the easy route to IPv6 and until they are provided the support, or like my experience two days to immenent failure they aren't likey to do sod.
I have a Linksys WRT54G v8 and there isn't even the possibility of installing a version of DD-WRT that supports IPv6 :(
Jumpstart the tartan drive.
I suspect the switch to IPv6 will take about as long as the switch from DC to AC electricity. IPv4 is so ingrained in hardware and software that it will take decades after the last IPv4 only hardware has been produced for the switch to occur. Additionally, the cost of IPv4 addresses is going to need to rise above the couple of dollars a year it currently is at. http://cityroom.blogs.nytimes.com/2007/11/14/off-goes-the-power-current-started-by-thomas-edison/
Well, it is already implemented. Maybe not with much US based businesses but AMS-IX saw a ten fold increase in IPv6 traffic this year: http://www.ams-ix.net/mnt/verliernix/img/flow/ipv6/all/ipv6bps_yearly.png
I tell this story all the time, and I'll tell it again.
I *tried* to build up a new fiber network in downtown St. Louis using IPv6. I couldn't get the address space!
It's insane - I could get 3x/24 blocks (non-sequential) assigned to my ASN, but in order to get an IPv6 allotment, I had to show proof that I *already* had utilized a full /24 of IPv6 addresses (which is NOT 256. It's 256*256*256!) They said to get it from my upstream provider - they said they don't do that, get it from ARIN. I go back to ARIN, ARIN says "They're full of it, get it from your upstream provider."
Even more insane? IPv6 allotments are FREE! I had to pay per year for an IPv4 allotment, but the free stuff? Pfft...we have it, we'll never run out of it within your lifetime, but you can't have it.
WTF?
Karma: Chameleon (mostly due to the fact that you come and go).
You've hit the nail on the head. NAT dovetails very nicely with the "castle mentality" many network administrators have: this is mine, and you can't touch it. It's about control, and there are fewer more tangible symbols of control than your own network numbering scheme. Nobody wants to give up that sense of control by moving to IPv6.
But since 2005, you don't have to: IPv6 now has private address ranges just like IPv4's. Also, NAT has always worked with IPv6.
Since 2005, all four combinations of address spaces can work in principle: IPv4 inside, IPv4 outside, IPv6 outside; IPv4 inside; IPv6 outside, IPv4 inside (with DNS proxying), and obviously, IPv6 inside with IPv6 outside.
Whether this "castle mentality" is appropriate is a different debate. Moving to IPv6 for the public internet is too important to get bogged down in talking about NAT.
Your post demonstrates my point perfectly: the colon-separated hex notion screws up URL parsing, requiring algorithm changes for everyone, and as you see, lots of people still haven't gotten it right. Dotted-quad notation wouldn't have required nearly as much effort. The new notation was an unnecessary barrier to adoption.
We're talking about Joe Sysop and Joe Programmer, whose opinions regarding IPv6 are far more important than Joe Plumber's. These people see IPv6 as something exotic and frightening, and try to avoid it as long as they can. IPv6 should have been made as similar to IPv4 as possible; instead, the IETF tried to do too much too fast, and now we're paying the price.
This is a minor nit - ARP cache timeouts are normally on the order of 300 seconds, not two minutes.
A less minor nit is this: IPv6 does not help decrease the size of routing tables as seen by major providers. Nor does IPv6 reduce the burden of sending routing updates so that routing updates are propagated faster than the underlying rate of change of usable net paths. (Enterprise subnets, whether IPv4 or IPv6, don't generally propagate into the routing announcements as seen by the big carriers.)
The compelling argument, for me at least, is that IPv6 is really a new internet that runs along side of the existing IPv4 net - there is no direct interoperability. This means that pretty much any new expansion of the net is going to require IPv4 connectivity, and IPv4 addresses, to reach the legacy net. And that makes IPv6 redundant from the user's point of view. That sort of drains the oil out of the IPv6 crankcase.
Of course the biggest argument of all is that IPv6 does not solve the hard issues of propagating routing information and finding usable paths across the net, particularly as the demands of human-conversational traffic and the political acts of nations are (unfortunately) driving routing to become increasingly aware of the types of traffic being routed.
I'm waiting to be shown that I'm wrong - I helped do the very first calculation of IPv4 address consumption back in the mid 1980's. And I was in the group at Sun back in the very early 1990's where IPv6 took form. I spent time at Cisco wrestling with questions like how to efficiently mechanize 128-bit longest-prefix matching on 32 and 64 bit hardware. And my company currently has IPv6 testing products. So I've been watching IPv6 for what will soon be two decades.
To me one of the tilt-points of IPv6 will be when I can go into Frys Electronics and find IPv6 capable print servers and other widgets of that ilk on the shelves.
I saw ISO/OSI come and go (I was rather a fan of TUBA - which included the use of ISO/OSI CLNP for the new IP layer - when the various IPv4 alternatives were being considered in the early 1990's.) It would not surprise me to see IPv6 go the way of ISO/OSI.
Ohforgod'ssake. You're going to *type in* raw IPv6 addresses in a URL? I don't *think* so. I do it for debugging, but there's no way I'd ever ask an end user to type one in, and if I did there's no way the end user would do it. Which makes it a non-problem.
Decimal dotted quads are too big, and they wouldn't look like IPv4 dotted quads anyway. For instance, my IP address as a dotted quad is:
32.1.31.56.2.6.0.0.2.23.191.255.254.133.196.90
In hex, it's:
2001:1938:206: :223:dfff:fe85:c45a
You really prefer hex? You really think that's going to look familiar and comfy to a person who can't handle the hex format? Naw, dude - this is really a great way to weed out people who shouldn't be on staff - if they can't handle the hex, there are a lot of other much more important things they also can't handle, in IPv4-land as well as IPv6.
Admittedly, there's always resistance to new stuff by a certain number of people, and that's perfectly understandable and not grounds for firing. But those people will get over it after a bit of hands-on.
Sounds too familiar.... Kinda like the damn analog tv to digital switchover which been planned, discussed and advertised for YEARS!! Then it got delayed....AGAIN!! Cuz those 6 million viewers think analog tv works just fine and don't want to switch to digital and they don't comprehend that fact digital is better using a $50 converter box.
Sheesh. Ah well.. good luck with IPv6. I know it'll be the holy grail for the Internet but right now they don't see the immediate benefit and won't upgrade unless they are forced to.
A nice pipe dream.
People are used to having 1 or 2 IP addresses handed to them. Most probably only use one - they stick their cablemodem into their NAT router and be done with that. ISPs know this, and you can bet good money that when residential people get IPv6, they may give them a large range of valid IPs, but really, only route 1 or 2 to them, because they know users will only use 1 or 2. And pay for more, if they need it. And the majority of users will do that - they'll take their IPv6 pipe, and stick on a router, and probably do IPv6 NAT.
No, the era of direct-connected machines is long gone - even if the user had a regular normal firewall and a 1:1 mapping of devices to IPs, you're going to have to tell them how to open a port on it so they can play their game again. And it'll probably be more confusing, since they want only one machine to get that traffic.
And yes, going around NAT is annoying, and breaks some applications. However, the interesting thing is how many applications aren't broken. Or have implemented functionality to work around firewalls and NAT. If you go back to just over a decade ago, playing an online game may easily require 10-15 ports open (TCP/UDP) on your firewall. Nowadays, it's down to one, or in some cases, do nothing. The ports I opened on my NAT router were for HTTP, ssh, and BitTorrent, and I still do online gaming (Xbox Live, Playstation Network) fine without UPnP (disabled on router). And yes, people invented STUN to help get through NAT, as well.
About the real benefit of IPv6 is to make viruses and trojans spread slower as they now have to send packets to more hosts, and there will be more holes in the address space, so chances of success will be limited. But the chance of two people plugging in 2 VoIP phones into a random network and have them work always is gone (unless they're Skype phones, which use STUN and a bunch of dirty tricks to get around NAT and firewalls...).
No company wants their inner network visible to the outside world (which IPv6 requires unless one uses kludges.)
This very much depends on what you consider to be "visible". You can (and should) firewall incoming traffic, which means someone can't actively scan you. Once you've done that, someone can only gain information about your internal network by looking at the traffic generated by your network. If you think NAT protects you from this then you're sorely mistaken - NAT will only hide the source IP address, you can still gain a lot of information by traffic fingerprinting and other methods.
No company wants to use a protocol with zero real world support for encryption unless you go to a higher layer, or tunnel over IPv4.
I'm not sure what you mean by this. Under IPv4, most encryption is done using SSL - IPv6 doesn't change this, SSL still works and is still used. IPv6 also adds IPSEC support (which has since been backported to IPv4, but it originated on IPv6 and works very well there). So in what way does IPv6 have "zero real world support for encryption"? If anything, it has better support than IPv4 because encryption was written into the spec from the start.
No company wants to change their entire IP address range because they change ISPs.
This really shouldn't be a major problem - if you're using autoconfiguration and DNS then the amount of work required to renumber a network is minimal. You can also do a soft migration, so you can keep your old IP addresses in service for a while after your new IP addresses are put into service.
Some boxes have an infinite DHCP lease?
If that's your setup, you need to get a network manager who has a clue.
Businesses know that IPv6 is broken, untested, and unstable in production environments, with hastily written standards that factor little in the way of security.
You post indicates that people *think* they know that IPv6 is broken, untested, unstable and insecure. In reality, these people are grossly misinformed.
http://blog.nexusuk.org
Is that really a NAT problem or is it a SIP (VOIP) problem?
It is a general peer-to-peer problem. NAT breaks peer-to-peer communications - there are workarounds (such as STUN) but they are not, and cannot be, reliable. The only solution is to remove NAT from the equation.
SIP certainly could have been designed better IMO. Wonder who first conceived of embedding the IP address, normally only a part of the IP header, in the application data, as a security measure no less!
It's actually a pretty sensible idea: Your phone registers with a SIP registration server so that other users can find it - lets say your ISP runs the registration server, so people know to place calls to r7@yourisp.com if they want to phone you (very similar to email). So I phone r7@yourisp.com, my phone talks to your registration server and says "hey, I want to call 'r7'". Your registration server then talks to your phone and says "there's a call for you", your phone sends back a message to the registration server saying "answer it" and that gets forwarded on to my phone.
Now the clever bit (which requires the IP addresses to be embedded) - the 2 phones negotiate (via the registration server) for the IP addresses and ports that will be used to carry the voice data. This means that the registration server is not involved with passing the voice data - this is a Good Thing for 2 reasons: 1. the server doesn't need as much CPU, memory, bandwidth, etc. 2. Most importantly, the route that the voice data is going over is as direct as possible, so you should get a nice low latency.
It gets more important to do this if you start doing stuff like transferring calls - if I'm talking to you, and you want to transfer my call to someone else, your phone will issue a "reinvite" message to my phone, telling it where to direct the voice stream. This means that once the call transfer is completed, your phone is nolonger involved in the communication at all.
If your phone is behind a NAT, it won't know what IP address and port its voice traffic will be transmitted on once it is NATted. You can try and work around this by using STUN, but it isn't entirely reliable since this requires your phone to make some educated guesses about what your NAT is going to do with the traffic - sometimes it'll be right, sometimes it'll be wrong.
This is not only ineffective security it also ignores the ISO seven layer stack.
IP itself isn't an ISO sever layer protocol - never has been, never will be. What you probably mean is that it ignores protocol encapsulation boundaries. And you're right - it does.
But sometimes you have to do that to get the results you want - any other peer to peer protocol is going to do the same thing (e.g. bittorrent) because it has to tell the peers where to connect to.
That's why SIP doesn't play well with NAT. Has nothing to do with NAT itself, IMO.
*NO* peer to peer protocol can play well with NAT. this isn't a flaw in the protocol, it is a simple fact of life. NAT breaks the end-to-end nature of the network, peer-to-peer requires an end-to-end network, ergo they are incompatible technologies.
The "solution" to doing VoIP without an end-to-end network is to use different protocols for the client-server and server-server parts of the system - make the server-server part a peer-to-peer protocol (such as SIP) and the client-server part a client-server protocol. This means that the media path is going to be longer and the servers are always going to have to route the media path meaning a higher cost and a lower quality of service.
http://blog.nexusuk.org