Slashdot Mirror
How Ready Is IPv6 To Succeed IPv4?
New submitter unixisc writes: Over the last 2 years, June 6th had been observed as IPv6 day. The first time, IPv6 connections were turned on by participants just for a day, and last year, it was turned on for good. A year later, how successful is the global transition to IPv6? According to Cisco 6labs, adoption rates vary from 50% in Belgium to 6% in China, with the U.S. coming somewhere in the middle at 37%. A lot of issues around IPv6, such as the absence of NAT, have apparently been resolved (NAPT is now available and recognized by the IETF). So what are the remaining issues holding people up — be it ISPs, businesses, consumers or anybody else? When could we be near a year when we could turn off all IPv4 connectivity worldwide on an IPv6 only day and nobody would notice?
Absence of NAT is a feature! If not THE feature of IPv6!
seriously, as long as it goes end to end, and I don't have to set it up, I don't care which method goes.
if this is supposed to be a new economy, how come they still want my old fashioned money?
Here in Canada Shaw communications doesn't make IPv6 available to residential customers. To compensate I have been using Hurricane Electric IPv6 tunnel for a few years now.
Remember when Intel pushed IA64 for years and years with little success? Then AMD rolled out x86_64 and it spread like wildfire. Intel has been making "AMD clones" ever since.
You know how many parts of the world have skipped deploying millions of miles of phone wire and jumped straight to cell towers?
You know how everyone said they couldn't switch to Linux because they were familiar with Windows? Then MS rolled out a new Windows with a drastically different UX, and everyone jumped on it? Or how OpenOffice is more similar to pre-ribbon Word, but people who couldn't go to OOo because it had different menus plunked down good money to use the new Ribbons?
In each of these cases, the important piece wasn't familiarity or similarity. It was compatability.
IPv6 is not backwards compatible with IPv4. My IPv6-only client cannot talk to your IPv4-only server and your IPv4-only client cannot talk to my IPv6-only server. For these reasons, I don't believe that Belgium has 50% adoption. I don't believe that the U.S. has 37%. And it can't be like cell towers and just leap-frog the old. Because cell technology is compatible with non-cell technology.
I'm waiting for somebody to come out with IPv7 that is compatible with IPv4 and convince Cisco or Juniper to put it on their boxes and submit it to IEEE. It might not even have to be IPv6-compatible to displace IPv6. Just like x86_64.
I think most people don't see spam anymore because of high-quality spam filters. At least, among technical people who would care enough to fix the problem.
"First they came for the slanderers and i said nothing."
Actually IPv4 is more CPU intensive due to where the checksum was implemented. IPv6's issue with hardware is more about memory.
At least in the UK, numerous residential ISPs, while they may not have IPv6 offerings yet have certainly been only providing routers that have IPv6 support for the last few years.
Change is certain; progress is not obligatory.
I have Gig Fiber coming into my research lab with a /24 subnet of IPv4. We assigned about 100 IP's right off the bat (mostly tunnels to other labs and remote access for outside researchers), we added another 12 or so this last year for new people/projects. So with 140 (give or take) IPv4 IP's left, why would I bother changing to IPv6.
IPv6 adds NO additional useful features to our network, none. Yet would add some expense in switching over (our firewalls are PFSense, so they're ready for IPv6 if there's ever a need to switch over). We have about 90 workstations, 10 servers, and three 384 core clusters, all just chunking away on their 10.0.x.x networks.
It will be decades before IPv4 traffic can't communicate with IPv6 networks, and if you want to run your networks on IPv6 then it's up to you and your service provides to bridge to IPv4 if you want to communicate with my systems.
So, until there's a REAL reason (read, worth the expense and time and training) to change over, I don't see it happening. Worse case, if we get a client that's valuable enough and they're on IPv6 only, we'll setup a bridge ourselves just for that client (but it hasn't happened yet).
Comment removed based on user account deletion
Honestly, the only reason I haven't switched to IPv6 on my internal network is because I cant remember the damn IPv6 addresses. O_o
The official "switch-on for good" of IPv6 a year ago was entirely seemless in my experience. There wasn't anything to fix, as nothing was broken, and IPv6 autoconfiguration handles everything so there isn't even any setup involved, it just works. This simplicity will be a boon for non-technical users once the IPv6 rollouts gain steam.
Unfortunately the ISPs are still dragging their feet and so public rollout is slow, but it's an always upward trend, and the adoption curve is close to exponential so IPv6 will be ubiquitous before long. So many ISPs are currently planning their rollouts that there's going to be a sudden upsurge when they finally appear.
People shouldn't talk about switchover to IPv6 though, that's not how it works. IPv4 and IPv6 networks run together side by side, and you use both together. Your application (eg. browser) generally picks IPv6 if your destination is accessible on that network, or else it falls back to IPv4. This is all automatic of course. It's better described as a switch on of IPv6 by your ISP followed by your gradual increasing use, not a switchover. There is no plan to switch off IPv4. The last remnants of IPv4-only equipment could still be around and operational for decades ahead.
IPv6 works so well that I recommend everyone to get on it as soon as they can. You'll be able to see 100% of the Internet, whereas if you don't have IPv6 then you're only seeing a part of it. IPv4 is by far the larger part for now of course, but it's not all of it, and the parts you can't reach are growing daily.
Happy First Anniversary of the official turn-on, IPv6! :-)
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
How ready is Perl 6 to succeed Perl 5?
I was just trying to be facetious with that comment, but then I thought of asking "How ready is C++ to succeed C?" or other silly things. As someone who programs in C++, I see little reason to use pure C, yet people do. When using Python, I use Python 3 and see little reason to use python 2.7, yet people do. People just don't like change, and they often won't do it unless absolutely forced to. Others here have already made this point, but the whole world isn't going to switch to pure IPv6 without some incentive, to practically force them to do it, it seems.
Recap: It's not a question of how ready IPv6 is to succeed IPv4, it's a question of how ready people are to adopt IPv6, at the ISP and consumer level. Services will follow when there's a demand, as someone else also noted.
Considering the average high-traffic router gets replaced every seven years (roughly), I have my doubts this is even a problem.
I would imagine such routers aren't handling significant amounts of traffic and even so, without the need for running checksums, no fragmentation validations/calculations, jumbograms, no TTL field validations/calculation, I have doubts this really is an issue.
Change is certain; progress is not obligatory.
You do realise that this is complete garbage. The reason that we need IPv6 is that IPv4 was never designed to scale to every household in the world. 4 billion addresses was never enough for that. We have extended IPv4 by about 2 decades through the use of address sharing but the amount of sharing is now going from 1 addresses per household to less than 1 address per household and the tricks that allow address sharing at the household level without to much administrative pain don't work between households.
To illustrate, let's look at phone numbers.
Imagine a phone company with 6 digit numbers which wants to give users world-accessible phone-numbers. What did the phone companies do? Easy: Just add prefixes to the numbers and everybody is happy. The old numbers stay valid, you can still connect within the old network(s), nobody has to remember new numbers.
But what if phone-numbers would have been expanded the "IPv6-way"?
Then you would have your old number and would receive a completely different new number, which would also be in an incompatible format (maybe letters instead of digits). Then you would have to update all your phone numbers everywhere, to "switch over". of course such a scheme would fail instantly and that's why IPv6 continues to fail.
The IPv6 adherents just don't get it. If the IPv6-designers were smart enough to just extend the IPv4-address space we would all be running IPv6 already, because it would require no reconfiguration of routers, no reconfiguration of DNS names, no reconfiguration of anything.
But these morons thought that a billion people will just change all their addresses just because they tell them. Well, it doesn't work that way.
You have always been able to hide as many devices as you like behind NAT or similar, whether IPv4 or IPv6. Thus it's impossible to enforce and if you do, it will just encourage NAT propagation for IPv6 as heavily as it was for IPv4.
Some blinkered people still suggest that IPv6 transition requires you to immediately renumber every machine and device you have with its own globally-routable address immediately and fail to see that what will actually happen is that people will replace their gateway with a dual-homed machine (effectively turning it into a 6to4 gateway) and thus want to preserve NAT functionality for a while.
Only the gateway is on the globally-addressable net at the moment, only the gateway is seen by the outside world, only the gateway NEEDS to change. The rest is one of those things that won't happen because - once the gateway is changed - the rest don't need to change for the rest of their lifetime.
The fight against NAT is actually, from my point of view, the thing holding people back. Sure the IoT is cool and your firewalling should be in place, etc. but there's nothing fundamentally wrong with NAT because just about every device on the net today is using it, and it doesn't cause enough problems to care about for the most part. However it solves an enormous number of problems, including quite what to do about an IPv4->IPv6 transition where you don't want to have to find and renumber every damn device with a MAC that's on your premises (or that probably don't support IPv6 anyway).
If people dropped the attitude and let people transition, maybe ISP's would start using it.
However, I'm implementing my rule here - you can talk about IPv6 when your website and email servers are offering AAAA records. So that kills any discussion on Slashdot or The Register or any number of "tech" sites about it, despite nearly a decade of promises that they are "testing" it.
My site does. My email server does. I regularly pass a lot of email via IPv6 to GMail and other IPv6-ready services. Until then, Slashdot is just a news site, not a tech site.
What's so tricky about The very large company that I work for ... has a *huge* 10/8 network?
"I don't know, therefore Aliens" Wafflebox1
When people talk about 'breaking end to end connectivity', what do they mean? Do they simply mean an uninterrupted path from the source address to the destination address, as specified in the IP header?
The way I understand it, end to end connectivity means that the packet should travel directly from the source address to the destination address without having its address headers altered. It is fine for it to travel through a gate, a firewall inspect whether its source address has a pass or not, and then ushered in: that does not break end to end connectivity. But when a NAT firewall takes its destination address and replaces it w/ one from RFC 1918, that breaks end to end.
Let's consider a postal analogy of this. If you send a mail to someone in 123 Elm Street and it gets there, you have end to end connectivity - your letter got to his door and he picked it up when he opened his mailbox. But if you sent a parcel to that same guy, and he gets a slip in his mail box to go ahead and pick it up in the nearest post office and if he doesn't, it remains there in some mailbox, and gets returned to sender if not picked up within 3 days, that breaks end to end. It's this - the parcel didn't get to the destination, just like NAT packets don't: the parcel got to a point in b/w, and waited to be picked up by the recipient. Same thing here - the NAT packet stops at the gateway, and gets a new private address in which to go and find its recipient.
It isn't (and never was) a question of capabilities. It is a question of cost. Most decision makers at every level from individuals on up to CEOs view IT (correctly BTW) as an expense, not a corporate treasure. The IP6v train left the station without the capabilities required to make eventual I{Pv4 replacement cheap and easy -- backward capability and NAT. Lots of people tried to point out that was a mistake. It was done anyway, and the same folks that didn't understand why it was a mistake still don't seem to understand why it was a mistake.
Compared to the average business or public organization, our home setup here is not very complex at all. But we still have about two dozen devices whose software would need to be upgraded in order to change from IPv4. to IPv6. And we'd probably have to buy some new kit because some of the routers and software probably have flawed IPv6 implementations -- if they have IPv6 at all. And, of course our ISP is IPv4. Assuming they can/will deign to talk to us using IPv6 it's a safe bet that "upgrading" would cost us more time and money.
And what do we get from all that? IFAICS all we get is the capability to expose all the digital devices in the house to external hackers. Why would we want to do that? Much less spend time and money to do that?
It'll most likely be a long, long time before IPv6 completely replaces IPv4.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
- It's the firewall, not the address translation, that protects your devices, and those are there in both IPv4 and IPv6
- IPv6 too supports NAPT if required. Only difference - you won't need port translation, since the IPv6 NAPT is a 1:1 mapping b/w addresses, as opposed to the 1:n mapping in IPv4, which was what made using the ports necessary
The IP for every lightbulb is one of the luxuries that came about b'cos of the boundary at which the Global Prefix and the Interface ID were split - a wrong choice IMO.
Let's take a subnet. What's the maximum number of hosts any subnet is likely to have? Imagine a rock concert that sells 100s of tickets, and everybody in the stadium has their phone accessing the internet while it's on, and a worst case - only 1 hotspot for them all. What is the maximum number of hosts it might service? Whatever it is, I doubt it would even be anywhere near 4 billion - which would be gotten from a /96. Yet, the boundary is fixed at /64, and whenever anyone raises that, we're told that we'll never run out of IPv6 prefixes (not addresses, mind you) due to the grains of sand argument.
Why is the Interface ID given a whopping 64 bits? The ONLY reason I've seen given for that is auto-configuration. Well, it is nice that there are mechanisms to automatically allocate Interface IDs, but even for that, 64-bits are overkill. And directly tying those IDs to hardware IDs, be it MAC addresses or SCSI addresses or EMEI numbers is a security risk - which is why there have been recommendations not to use those.
Just like the world's population is unlikely to ever be in the range of 2^64 while we're still on earth alone, it's just as unlikely that any single router - wired or wireless - will ever have on its subnet anywhere even close to 4 billion users. Yeah, we could have used just the bottom 24 bits of the address for the Interface ID and gotten 16M nodes (to match a Class A classful network), or the bottom 16 and gotten 65536 nodes, and it still would be plenty for a single subnet. Well, let's say that we assigned the bottom 32-bits to the Interface ID, and that would have been enough. 4 billion is an adequate size to pick a number that has a low enough probability of matching anything else within the same subnet, and in the event that it did clash, ND and DAD would eliminate that choice and assign something else.
In the meantime, RIRs and ISPs have had varied policies about allocation - some allocating /48s, some /56s and some going all the way down to /64. So while the Interface ID is bloated - and hence your lightbulb example - there ain't too many global prefixes to distribute. Which is why I suggested that the Interface ID should be locked at the 96th bit, while the global prefix should end at the mid point. The RIRs can then assign either /32 or /48s to the ISPs, who then have to assign /64s to their customers. That would also enable things like hierarchical subneting or lending structure to both subnet addresses as well as Interface IDs. Ultimately, that is what's more likely to burn up addresses than the actual physical entities using them.