Was working on ipv6 proto's back in the late 90's. It's salutary how slow some infrastructure changes.
PEAK IPV4? Global IPv6 traffic is growing, DDoS dying, says Akamai
Broadband and IPv6 are hot – and distributed denial-of-service attacks and IPv4 are not. Well, that's according to Akamai. The cache-and-carry-on biz said in its latest State of the Internet report that, for the first time ever, the average connection speed for netizens is more than 4Mbps, meaning your average punter has a " …
COMMENTS
-
-
Tuesday 30th September 2014 20:58 GMT channel extended
Old School Machines
The early routers and switches were IP4 only, as time went on they were replaced with machines that could handle both protocols. This is why there is still only one internet network.
Manufactors saw IP4/IP6 compatible machines as a marketing tool at first and now you can't buy a router that only does IP4, not new anyway. The long slow rollout of IP6 is due to the fact that it started early, and wasn't seen as urgent.
-
Tuesday 30th September 2014 21:54 GMT Tom Maddox
I'll take my best shot
I am not a network engineer, but I'll take my best shot. IP (Internet Protocol) is basically Layer 3 of the OSI model, which means it can run on top of Ethernet (or whatever your data link protocol is), and it can carry anything from higher up the networking stack. In practice, there are some additional complexities with higher-level protocols and applications, especially those that use IP addresses instead of host names, but a lot of applications should just work. The biggest problem is getting a significant chunk of network infrastructure to run IPv6. Not only does the protocol itself need to be deployed, but addressing schemes need to be vetted, routing and firewall rules implemented, and all the inevitable snafus need to be ironed out. Logistically, it's a significant challenge, probably more than it is a technical one, and it involves a tremendous amount of time and expense, and it requires IPv6 expertise that is not very widespread at the moment, which means that more mistakes than normal will be made along the way, resulting in reputational damage to the implementers.
Beyond all of that, there are plenty of endpoints that either don't run IPv6 still (think: printers) or run it poorly (Windows XP), which means that ISPs and other network providers will need to run in a hybrid mode, employing NAT or protocol tunneling, to support the legacy protocol until the final consumers make the migration. Which, of course, means that the consumers need to be educated and migrated, not so bad when you have a well-educated user base (or at least a captive and docile one), but daunting when you consider how many users will need to be wrangled into compliance and how few of them will even understand why.
So, it's not quite as hard as rebuilding the Internet, but it's still no small task.
-
Wednesday 1st October 2014 09:18 GMT itzman
Re: I'll take my best shot
I WAS a network engineer and casting my eye over that I couldn't find much to fault it.
It bears a little amplification.
firstly it is a new network. to use it fully requires that every link in between be fully V6 or able to tunnel it. I think.
Secondly NAT will not go away. NAT is here, works, already implemented, and has many advantages for e.g. dumb consumers, and indeed corporates who can spend the time making it work right, insofar as its detractors consider that statement has any meaning.
Thirdly, it will take years to deploy. legacy kit will still be there in IPV4 in 20 years time, I am sure.
The problem is it doesn't actually offer any advantages I can see that mean you will rush to deploy it if you have V4 addresses already. I actually envisage that many organisations will deploy it internally long before they get rid of some NAT that turns it onto a V4 for tunnelling across the internet.
Finally, security and anonymity are looking to be bigger issues than running out of net numbers these days. so even if IP stays, what are the odds that some kind of other protocol replaces UDP/TCP to add some measure of man in the middle security and indeed, given the endless argument about who pays for the internet, what are the odds that some kind of 'chargeable packet' field isn't added somewhere. Imagine a field that increments every time it passes a node, representing the cost of getting that packet across a given route.
.
Back in the day, every year was going to be 'the year of Unix' . Well there never was a year of Unix, but ever since I first heard that phrase, one by one alternative operating systems have withered and died, until. we pretty much have Unix or Linux running most things apart from custom hardware with real time needs, and Microsoft.
Novell netware, NET BEUI, token ring, X-25 - X-400 none of these have vanished altogether: the key is you don't deploy them in new systems.
Some version of IPV6 will probably carry us through the next 30 years, but there will never be a year of IPV6 either.
Just slow steady incremental growth where it makes sense, once its as stable and reliable as V4 is.
Id like someone to comment on how big a BGP routing table has to be with IPv6 as well.
-
Wednesday 1st October 2014 11:28 GMT The Vociferous Time Waster
Re: I'll take my best shot
With reference to your BGP question it depends on a lot of factors but the biggest is the summarisation one.
If networks learn from their mistakes with v4 then there will be enough opportunities to summarise routes at points in the networks and that dramatically reduces the size of the table. The way that addresses are being allocated with massive amounts held back for future use suggests that some planning and thought has gone in to it so we must keep our fingers crossed.
-
Wednesday 1st October 2014 17:50 GMT ZeroSum
Re: I'll take my best shot
Links in the middle can be between single-stack IPv4 hosts with IPv6 packet forwarding based on an MPLS label. That isn't tunnelling.
There are advantages to IPv6 but they are currently confined to cases like RFC 1918 exhaustion and CGNAT bypass for ISPs and Content providers. As adoption grows Metcalfe's law will create more short term cases for deployment.
There are fields that decrement every time a packet passes a node. Which could be used for same purpose but that won't happen as it would require too much inter-as cooperation.
The unix analogy and steady growth as IPv6 is increasingly integrated is good.
The Default free Global Routing table for IPv6 has about 20k prefixes in it, compared to 500k for IPv4. Since organisations can be given larger prefixes it should remain smaller for some time unless lots of small organisations start getting their own ASNs as well.
-
-
Wednesday 1st October 2014 03:53 GMT Yes Me
Not isolated
> I thought that IPv6 networks were completely isolated from the IPv4
Er, no, that would have been a silly plan. The actual plan was that every ISP would go dual-stack (IPv6 and IPv4 on the same wires and boxes). That works -- it's what many ISPs do already -- but for some it appears more expensive than going straight to IPv6 and supporting legacy IPv4 by tunnelling or translation. What is sad is the number of ISPs who are now being left behind -- most of the UK, for example. What's even sadder is major players who are only accessible by legacy IPv4: shame on the BBC, and even more shame on Vulture Central.
-
Wednesday 1st October 2014 22:28 GMT Roland6
Re: @intrigid
>I thought that IPv6 networks were completely isolated from the IPv4 internet, and that switching to IPv6 would basically require building a brand new internet from scratch
Basically there are many 'hoary' problems to be overcome for an IPv4 end system to talk with an IPv6 end system. However, the use of IPv6 as a carrier service for IPv4 has been working for many years and has been slowly deployed by the carriers. Reading Akamai's report, it seems that they noticed a slight decrease (0.9%) in the number of requests received from IPv4 systems, but a more significant increase in the number of requests from IPv6 systems. What Akamai don't go into is whether the IPv6 requests are actually IPv4 requests or pure IPv6 requests. Given that Akamai's main customers are the providers, I suggest it is more likely that what Akamai are reporting is that more carriers and providers are switching to an IPv6 backbone infrastructure, even if they are publicly still presenting a pure IPv4 service.
-
Tuesday 30th September 2014 20:52 GMT Uncle Ron
Dummy
I'm a total dummy when it comes to this stuff. Can someone succinctly state how 4 and 6 can get along? Couldn't the world just "switch over" during a weekend, or even shut the whole thing down for a week and convert? Surely it would be worth it to end the v4 nightmare (not just address availability) we have been living in for 2 decades. Shut 'er down and start up Friday a week. Huh?
-
Tuesday 30th September 2014 21:06 GMT Pet Peeve
Re: Not really a dumb question
IPv4 space is a tiny little corner of the IPv6 space. An IPv6 aware stack can reach both by design. You can do an IP conversion here to see what that looks like.
Doing the opposite, seeing an IPv6-only site from IPv4, is a little trickier, and it requires you to use a proxy service.
-
Wednesday 1st October 2014 04:00 GMT Yes Me
Re: Not really a dumb question
Um, it's a bit more complicated than that. The techniques that site seems to be discussing (Teredo and 6to4) are pretty much obsolete - they were useful a few years ago when very few ISPs supported IPv6, but today you should really scream at your ISP that you want native IPv6 support. That would apply whether you are a domestic user or an enterprise customer.
-
-
Tuesday 30th September 2014 21:13 GMT Charles 9
Re: Dummy
There's an IPv4 address space in IPv6, and there are ways to bridge between them. One concern has been firewall penetration, as NAT provided an additional layer of security by separating the address spaces naturally. Also, some businesses run OLD (Pre-IPv6) hardware they can't replace. A sudden changeover would isolate them.
-
Tuesday 30th September 2014 22:20 GMT rh587
Re: Dummy
"One concern has been firewall penetration, as NAT provided an additional layer of security by separating the address spaces naturally."
Indeed. Serving stuff to people is dead easy. As we've been upgrading servers we've been asking our bit barn to provision them with IP6 addresses as well as IP4, since every modern server OS can happily handle a dual network stack. Security/NAT isn't an issue - they're public facing web servers, so the security on them is set to be tight whether they're accessible via 4 or 6.
Really, for anything designed to be web facing, then provided it's got a sufficiently non-ancient OS that it runs a dual IP4/6 network stack, it's really just a matter of getting it assigned an IPv6 address (and updating your DNS records).
The key issue is the users. If ISPs actually started assigning IP6 addresses to users and configured their routers (which will all be dual stack anyway) to prefer IP6, it could happen quite quickly. They won't though because though everyone would be bloody confused by the disappearance of their nice 192.168 addresses and the reappearance of these long, confusing IP6 addresses, and many of them could have stuff sat on their network that has gaping security holes either by design (IoT), or bits they set up that they never intended to be accessible from the public internet - RPi home media hubs and the rest. If ISPs flushed a firmware upgrade to their routers (and I don't doubt at least some of them have left backdoors in so they can do that), they could in principle convert all their users to IPv6, but doing so would simultaneously expose billions of unsecured devices that were never supposed to see anything other than a 192.168 or 10.0 address.
As a result, the only people who can actually see our servers over IPv6 are people keen enough to tunnel, or the handful who have actually ahd it natively enabled by their ISP - usually smaller players with fewer customers or the odd business network that's made the jump. Us being on BT in the office means we have to tunnel to check our servers are actually accessible by those means!
-
Wednesday 1st October 2014 00:52 GMT P. Lee
Re: Dummy
>long, confusing IP6 addresses,
That's half the problem. The other side of the coin is that for IPv6 (with its long addresses) you *must* have rock solid DNS. Most people don't have that infrastructure for IPv4. All those times when you just knew the IP address are gone.
Many systems have IPv4 addresses in their configuration databases - moving to IPv6 would require new UI's, databases and validation routines to be built. All those hideously overcomplicated legacy firewall systems would need IPv6 addresses included for every IPv4 address (which may just be a NAT, not a real host which exists anywhere).
All those companies who think IP addresses are secret will need a mindset change. Lots of things we did for IPv4 are no longer relevant, such as NAT, double-NAT to link incompatible network ranges; using NAT as a "drop all" traffic permissions rule, blocking DNS to foil network discovery is a no-go unless you want a lot of pain indeed.
IPv6 has a different network design, it is not just IPv4 with a bit more address space.
-
-
Tuesday 30th September 2014 23:01 GMT Martin-73
Re: Dummy
I was under the impression that the 'separation' by NAT routers was kinda a byproduct, and can easily be worked into a 6 only router* by just blocking anything coming in over the WAN interface by default, allowing port forwarding much the same as IPv4 + NAT, but just not requiring the IP address MAPPING, as in instead of "anything coming in on the WAN on port 80, map to port 6680 of 192.168.1.230" you'd simply say "Anything coming in on 3D8B:0004:773A:FB01:: port 80, route straight through" ?
Or am I mangling it completely? (Genuinely interested because I'm considering switching to A&A)
-
Wednesday 1st October 2014 03:50 GMT Charles 9
Re: Dummy
"I was under the impression that the 'separation' by NAT routers was kinda a byproduct, and can easily be worked into a 6 only router* by just blocking anything coming in over the WAN interface by default, allowing port forwarding much the same as IPv4 + NAT, but just not requiring the IP address MAPPING, as in instead of "anything coming in on the WAN on port 80, map to port 6680 of 192.168.1.230" you'd simply say "Anything coming in on 3D8B:0004:773A:FB01:: port 80, route straight through" ?"
A byproduct, maybe, but a welcomed one, because local net addresses are just that: they're not meant to be exposed to the Internet, and most network stacks will interpret this as such. If not, some link in the chain is likely to realize, "Hey, this isn't a proper internet address" and reject the connection. IOW, odds are if you tried to use a local net address to connect to a LAN address behind a firewall, odds are the firewall won't even be aware of it.
Sometimes, the best defense is stealth, as in making it look as if your machine doesn't exist. Think of it like a hotel or hospital where the rooms can't be direct-dialed from the outside (room-to-room calling is unaffected) but have to go through the front desk first. The front desk is the NAT firewall in this case even if outgoing calls are being routed automatically. If you tried to direct-dial a room, odds are the number is invalid and the phone company will block you, not even reaching the front desk.
-
Wednesday 1st October 2014 07:10 GMT Ken Hagan
@Martin-73
Exactly right, which is why it is so frustrating when people say
"One concern has been firewall penetration, as NAT provided an additional layer of security by separating the address spaces naturally."
That's just FUD. NAT *is* a firewall plus address re-writing rules. IPv6 does not increase your exposure to the wider internet. Your ISP (well, A&A, certainly) will offer you a pre-configured router that has all this sorted out for both protocols.
Probably worth adding that IPv6 also has a "link-local" address range (non-routed, exactly like 192.168.x.y). You can configure all your domestic services to listen only on link-local addresses if you want belt-and-braces security.
-
-
-
Tuesday 30th September 2014 23:10 GMT mightysmooth
Re: Dummy
Translation - NAT64 being one example. Traffic from IPv6 only devices trying to get to IPv4 only devices passes through a gateway that can speak to both types of network. It basically takes traffic from the IPv6 network, unpacks the data from it, repackages the data as IPv4 traffic and throws it onto the IPv4 network. Same happens in reverse for traffic going the other way. Think of two people who don't speak the same language communicating through an interpreter. I've been working on NAT64 for the last 12 months, it has a lot of limitations although we are starting to get solutions to some of those problems now. It will be a massive help during transition.
As for the big switch off - its a bit more complicated than that. If you want to remove IPv4 completely from the Internet then that means that every network connected to the Internet also has to change or it wouldn't be able to communicate with the Internet anymore. We have many, many thousands of IPv4 addresses configured across thousands of devices in our network, even if we could switch it off it would take months to reconfigure it and prove it still worked - and that assumes that all our equipment supports IPv6 (it doesn't!). There isn't much that works without networks these days, how many power stations do you think could operate for long without any networking? It might be tricky to reconfigure our networks without any electricity to run them ;-)
As it is we have methods to allow the two protocols to co-exist, so we can convert the bits of network where the limited numbers of IPv4 addresses really matter (e.g. ISPs, WWW etc.) to IPv6 and leave the ones that don't (e.g. your average office LAN) on IPv4. IPv4 is with us for a long, long time to come.
-
-
-
-
Wednesday 1st October 2014 03:51 GMT Marcelo Rodrigues
"Each IPv4 address takes up 32bits whereas an IPv6 address takes up 128bits. That means extra processing power and memory."
The IPv6 header is significantly simpler than the IPv4. One of the goals of IPv6 was to be easier on routers - both by reducing the number of routes and by being lighter to process.
-
Wednesday 1st October 2014 12:25 GMT theblackhand
Migrating from IPv4 to IPv6
One of the major issues with IPv6 IS that performance for high end routers and switches is half the speed for IPv6 versus IPv4 and takes more memory.
Part of this is caused by the differences in address length - part is the expected growth of the global routing table due to the availability of more address space in IPv6.
This doesn't affect home routers (assuming they support IPv6) that rely on a default route via the WAN interface but global Internet routing table growth has already caused problems a number of times in the past when hardware limits have been reached.
-
-
Tuesday 30th September 2014 22:04 GMT Jamie Jones
The infrastructure has finally caught up to make this usable
I've been using IPv6 for more years than I can remember.
The problem then was that with overloaded tunnelbrokers, and numerous 6in4 and 6to4 hops between most long links, the link was always slower and less reliable than IPv4, so not a desirable preference.
Now I find long-distance links particularly (UK to NJ and UK to LA specifically) are always faster with IPv6, and so I mainly use that now.(*)
Indeed, over the last year, I've switched all my servers to use IPv6 in preference to IPv4 (although admittedly this basically affects outgoing initiated connections rather than incoming ones) - the majority using native IPv6 and the remainder using the very fast and reliable free Hurricane Electric broker. (http://www.tunnelbroker.net/)
So, the thing is, we've finally reached the point where IPv6 is better (or at least, not worse) than IPv4 which should be the tipping point in speedier takeup.
(*) I realise there is nothing inherent in IPv6 to make it faster - I'm guessing that my IPv6 connections are simply tending to use more modern and less congested links.
-
Wednesday 1st October 2014 02:56 GMT Anonymous Coward
Re: The infrastructure has finally caught up to make this usable
I have been running IPv6 via HE for a long time.. I'm seeing the amount of traffic coming and going slowly increasing. Just over 10% of my throughput for the last 188 days has gone through the tunnel.
I might have to actually work out how my ISP handles IPv6 (if at all) at some point. :)
-