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."
As a person who's involved in an implementation of IPv6, let me say that it's difficult to see it implemented without ubiquitous gigabit networks all around, as well as network equipment (routers) that run on the kind of CPUs we don't nowadays expect such hardware to run on. On the one hand, they've made stuff easier (no more checksums on IP level, addresses that tell you something about themselves); on the other they've made it more difficult (potentially quite a lot of headers before you get to ICMP for example, as well as up to seven addresses that any device must listen to, address sizes that don't fit a natural integer), but the network is also busier: network meta-messages fly around all the time - much more so than with IPv4, its ICMP, IGMP and ARP (ARP times out in 20 minutes; link-layer address mapping in IPv6 expires in less than a minute), and don't forget multicast: it's obligatory and used a lot on IPv6, meaning that routers will be so much more busy synchronizing.
Then again; the time that hardware and linespeed catches up, *will* come. It's just not now, and nobody is in a hurry either. But running IPv6 over lines that do 1 Mbps in practice, however doable; it wouldn't make anyone happy.
Religion is what happens when nature strikes and groupthink goes wrong.
Um, what the heck are you talking about? The ARP timeout is two minutes, not twenty. Speaking as someone who's also implemented IPv6 and used it pretty extensively, it sounds like you really don't know what you're talking about.
There is a known failure mode with ICMPv6 if you have a 127-bit prefix, but this is well-known, there's a fix for it in the standards, and the workaround is that you just don't ever use 127-bit prefixes. There's no particular benefit to using 127-bit prefixes, so this is kind of a no-brainer.
As for CPU consumption, again, what are you talking about? On the backbone, the proliferation of micro-routes for IPv4 is a *huge* problem. IPv6 route aggregation makes things *faster*, not slower, and consumes less CPU time as well.
If you are working over low bandwidth links, you might want to take a look at 6lowpan, which allows you to statelessly compress headers down to under twelve bytes.
Bottom line, the conclusions you've drawn are, as far as I am aware, complete nonsense. I'm sure you believe what you've said, and it's the result of real things that you saw, but without a bit more back story, I don't think it contributes any useful knowledge to the discussion.
No. You can do a lot more connections than that. First of all a TCP connection is identified by two endpoints. If you connect to two different remote addresses, the connections can actually come from the same local port number. That trick only works for TCP. For UDP there could be more than two parties involved, and such tricks would break. Also, you are not limited to a single external IP. An ISP could setup a separate NAT box for every n customers. But customers are going to get a worse internet experience, even if ISPs do spend more money on it. So before ISPs start doing such tricks, they will probably start offering IPv6 addresses in the hope that some users will no longer use IPv4 addresses. But I don't think many systems will refrain from requesting an IPv4 address over DHCP just because they were able to get an IPv6 address. However if ISPs do start deploying NAT boxes on a large scale, they'd better start offering native IPv6 at the same time, because that certainly can offload some of the connections from the NAT boxes. Even though a system may get both an IPv4 and IPv6 address, it isn't necessarily going to use them. Some systems will try IPv6 first, as long as the name resolves.
Do you care about the security of your wireless mouse?
and the basic low cost data planes are nat'ed
Instead of getting upset, get smart. ARIN is correct - you're supposed to get your allotment from your upstream provider, unless you're peering on the backbone (which it seems you aren't, since you have a provider). Your provider is probably used to the IPv4 way of doing things; the problem with that is that it produces fragmentation, which produces huge routing tables. In order to keep the routing tables small, the IPv6 allocation policy is to allocate hierarchically, so that you would get your addresses out of your provider's space.
When your provider runs out of space, you either renumber or fragment; renumbering is obviously preferred, and in v6 it's also easy, because you can do a soft transition - deprecate the old addresses, but keep using them for a month; by that time, all existing connections will be using the new addresses, and in the meantime all the connections that used the old addresses have faded away.
This is sufficiently different than the way things are done in IPv6 that it's not surprising that your provider doesn't understand it yet. So you need to help educate them - this isn't a situation where people are deliberately fingerpointing, but rather an opportunity for some education.
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.
We're starting to see this already. The Apple Airport Express/Base Station products are IPv6 capable and do 6to4 tunnelling when used as gateway devices, out of the box.
The HP CPxxxx series network printers are also IPv6 capable.
Now we just need the other tilt-point of broadband providers handing out IPv6 allotments, and we'd be set.