IPv6 growth is slowing and no one knows why. Let's see if El Reg can address what's going on Stop us if you've heard this one before: the rollout of IPv6 is going slower than expected. In fact, nearly seven years after the eternally optimistic World IPv6 Launch launched, we are still only at just over a quarter availability of the new internet protocol. But if that wasn't bad enough, the latest news is that even that …
...in the US. I live in the Chicago area and I my ISP doesn't support it. My cable modem has the ability built in to it's firmware and everything on my home network supports it but given that this is the USA we have bigger issues to worry about than breaking the internet. Don't worry though, we will get around to it someday soon. Breaking the internet that is, not implementing IPv6 on a national scale.
> A large proportion of DSL networks in the UK don't offer IPv6 and have nothing in the pipeline (and that includes LLU providers, not just the old BT resellers).
Sky does. I'm not trying to invalidate your statement, but they are presumably one of the "big boys"
People selling servers to the public will see an advantage. With costs reaching almost $20 per unit in a /24 quantity, it's a real cost which has to be passed on to the customer. At the same time they can offer IPv6 for free, making for a cheaper overall product.
Well, if you're in the business of allocating IP addresses, going out of stock is a problem. RIPE, ARIN etc don't seem to be running out of cash though.
But strictly speaking, we haven't run out of IPv4 addresses. What has run out is the RIR's pool of allocatable addresses and it's ability to persuade holders to hand space back or use it more effectively. So some of the legacy /8s etc. Which got complicated by people deciding there's commercial value, ie the sale of Nortel's /8.
APNIC and AfriNIC had different challenges by being late to the party, cover large territories & populations and tended to push for IPv6. Most of their IX's made v6 a requirement for membership. Or at least some plan to adopt it at some point because in the early days, v6 support on core-type routers was problematic.
Then there was mobile. Who were big in pushing for v6 so every phone could have an IP address. Not that they need them, and many of the mobile operators don't use it. After all, that would give less control over how handsets are used. And being able to make a VoIP call to 2001:0db8:85a3:0000:0000:8a2e:0370:7334 might be nice, but it's not exactly an easy number to remember. And EUI-64 functionality isn't necessarily a help given the mobile operator may not control the MAC address and has the IMEI/IMSI to play with anyway.
So for most users, it's not really an issue. They mostly care about URLs, email addresses, phone numbers. The IT department may care more, but probably want all external traffic routed/switched through a proxy/cache/firewall/compliance gateway and don't want their internals exposed.
But over 20 or so years providing Internet in wholesale & retail around the world, I've had many RFPs wanting IPv6 support, but only 3 customers actually getting assignments. And then they were mostly used so the IT depts could test & play with v6 support.
I guess that the basic issue is that for most people, IPV4 just works, and all their devices are behind NAT.
I stuck IPV6 support into the products I support some years ago, and from the occasional customer logs I see, it seems to be a thing, but that's all. Also, you can't really use it without a DNS; the addresses are impossible.
So who is going to volunteer for that?
There are indeed some simple issues with IPv6 such as they're difficult to deal with in the same simple manner as we've gotten used to with IPv4. But there are other problems for the end user. Because of the current state of adoption and sometimes broken implementation, IPv6 can cause troubles.
My ISP doesn't offer IPv6 so I need to use a tunnel, which in my case will mean that I'll be seen as coming from the US instead of Canada. That means that some Canadian shows will not let me watch unless I turn off IPv6. Note that Firefox defaults to IPv6 for sites where it is available - which also makes some misconfigured sites not load when they otherwise would. This sort of thing just makes me say, the *ell with it. I'll wait until this all gets sorted out. I'm probably not the only one who's starting to develop that attitude. If so, then we can indeed expect a downswing in IPv6 usage at this point.
""you can't really use it without a DNS; the addresses are impossible."
Yes, this is a rather serious downside to IPV6."
Well with IPv6 you can have "vanity addresses". For example "Fefes Blog", one of the largest German blogs has the IPv6 address 2001:4d88:3508::fefe:b106. Since the 2001:-prefix is almost universal, you end up with "4d88:3508" you actually need to remember. Those are 32 bits and therefore just as much information as an IPv4 address.
Well, Reg, it's because no sod ever IPv6 enables their website despite it not taking very much at all to do so.
Of course, a large, famous tech news site which constantly posts IPv6 articles with a mocking tone and uses an IPv6-capable host and CDN etc. would never do that right? They'd be right on it, like they have said every year for the past... 6 years I think?
IPv6 validation for http://theregister.co.uk
Tested on Mon, 21 May 2018 22:03:20 GMT
AAAA DNS record no AAAA record
This website is not ready for IPv6
Why should they; nobody wants, needs or uses IPv6.
Well, I'll answer the wants/needs part of that. Say you're stuck with a bog-standard "home" level broadband connection. You're stuck behind a NAT along with quite a few other home users. You decide that you want to put an FTP service up so that your aunts can see all the old photos that you've been digitising. Or some other such service (like email) that you want to self-host. You go to your ISP and ask them to open up a certain port and forward it to the right machine in your DMZ. What do they say? They say "sod off", followed by "unless you upgrade to a business package"...
Reply Icon
> You go to your ISP and ask them to open up a certain port and forward it to the right machine in your DMZ. What do they say? They say "sod off", followed by "unless you upgrade to a business package"...
With the justification that the terms of service for a consumer-level specify that you won't be running a server.
NAT killed the primary motivation for IPv6. Most of the other motivations are weak or flat out use flawed logic. (Remember the claim that IPv6 would stop spam? Instead it would make spam even more difficult to block.)
As a technical community, we need to go back and figure out what we want in IPv4-next. If we are honest with the evaluation, it's certainly not going to look like IPv6.
I think NAT in IPv4 is a _huge_ deal, because by default it gives good (although not perfect) protection to consumer devices running in a domestic setting where users tend not to have a clue about firewalls.
Move everyone to IPv6 and suddenly many of those devices become directly accessible from anywhere on the internet. Prepare for a huge spike in botnets and other 0wnage.
"Move everyone to IPv6 and suddenly many of those devices become directly accessible from anywhere on the internet. Prepare for a huge spike in botnets and other 0wnage."
Just like malware is mostly written for the most popular OSes, coz you get a bigger result with that, the low adoption of IPv6 currently means a lot less nasties on it. If my firewall logs are any indication. Everyday my logwatch report has pages of IPv4 buggers bouncing off my firewall, and rarely one or two IPv6 ones.
Though you are correct once IPv6 overtakes IPv4, if that ever happens.
Quote: "...You go to your ISP and ask them to open up a certain port.."
Misleading. Three steps are needed and ANYONE can run an external ftp service on their home network:
1. Make the proposed server on your home network have a fixed IP address (say 192.168.1.90)
2. Run vsftpd on the proposed server on a port of your choosing not the standard ftp port, say port 2001
3. Set port redirection on your ISP device so: redirect port 2001 traffic to 192.168.1.90
*
Done....no need to tell (or ask) your ISP anything at all.
*
Some comments though:
a) BT changes the IP adress of your internet connection about every two weeks. You will need to tell your aunts what the revised IP address is every time it changes. (DynDNS might help)
b) Please don't use ftp.....ssh/sftp is a much better choice for remote access.
Indeed, it is easy as long as you have a real public IPv4 address.
Personally I don't know whether this is a thing or not, but I've been hearing rumours about carrier-grade NAT and how it's going to be widely used by ISPs in the near future. This means that one public IP address gets shared by multiple users, each of whom has a private (RFC1918) IP address.
It's already used (and has been for years, I think) on the mobile networks. At least I assume it is, since my phones always seem to get an RFC1918 address from the network.
> Personally I don't know whether this is a thing or not, but I've been hearing rumours about carrier-grade NAT and how it's going to be widely used by ISPs in the near future.
CGNAT is widely deployed, and customers typically have no clue it is in use, until of course things break and nobody can figure out what is going on. Every tech I've met has no idea why customer one has "public IP" 100.64.1.5 when customer two also has "public IP" 100.64.1.5 when they live in different states when they get allocated IP's out of RFC6598 space.
Of course I get brought in when everything is fubar. The ISPs doing CGNAT are doing heavy rate limiting to make sure their CGNAT gateways aren't overloaded, and doing dirty tricks like redirecting all speed test sites internal so they look like they have great speed, until of course you have to transit outside of their network and find that you have almost no bandwidth besides the tricked out ports the carriers play around with.
But IPv4 is "good enough", except when it isn't. IPv4 won't die until it is too painful to use. Too many techs are blind to the world outside what they know.
Phew, a bit of front-line common sense. I had to check for a moment to ensure I was actually on ElReg as it seems the commentards aren't getting this at all.
Considering we've all been banging on about net neutrality for ages, even though people on this side of the pond give less than an airborne fornication for the US and its rules, this seems a little strange. What about peer neutrality? It was - and still should be, although I don't know how far up the tree the AOLers have been promoted at this point - one of the things that made the Internet possible. And by "internet" I don't mean the Big Blue E™ but the free exchange of ideas and knowledge and the free choice of protocols and infrastructure over which to do so.
Now I hear that not only is there a risk of a two-tier system emerging, it's actually happening. I know PlusNet trialled CG-NAT a while ago but I seem to recall it was dropped. Sadly, exactly the same thing happened to IPv6, it was trialled and then they bottled out.
If we want a world where the same bunch of corporate robber barons who micromanage our lives also control the only sites to which we can connect with our second-class connections, carry on ignoring IPv6.
Quote: "...You go to your ISP and ask them to open up a certain port.."Misleading. Three steps are needed and ANYONE can run an external ftp service on their home network:
It's OK to be wrong sometimes.
It's less cool to be wrong when "correcting" someone. Do some research next time.
FB actually wrote: You're stuck behind a NAT along with quite a few other home users.
Hint: Google "carrier grade NAT"
@Jamie Jones
Don't understand the correction of the previous post.
Everyone (even a retail broadband user) is "stuck behind a NAT". And most retail broadband users are at home with other people on the same LAN, i.e. with "quite a few other home users".
Maybe the original post meant that there were multiple broadband customers (i.e. multiple "home users" each with a separate contract with the same ISP)......but that's not exactly what the post said.
Perhaps you can amplify your statement about "wrong"?
Don't understand the correction of the previous post.Everyone (even a retail broadband user) is "stuck behind a NAT". And most retail broadband users are at home with other people on the same LAN, i.e. with "quite a few other home users".
Well, I'm not. And in fact, most residential customers are behind a NAT by choice - they aren't 'stuck' in that they can remove the NAT and have a NATless single IP4 address.
However, I think the confusion comes in in the reading of the following sentence:
You're stuck behind a NAT along with quite a few other home users.
He meant "you and a few other home users are stuck behind [the same] [CG-]NAT" not "you are stuck behind a NAT and other home users are also stuck behind their own NAT"
Add to that, I'm a grumpy old git...
As a technical community, we need to go back and figure out what we want in IPv4-next. If we are honest with the evaluation, it's certainly not going to look like IPv6.
If everybody did that, the honest answer for that IPv7 would probably be IPv4 with the addition of an extra 2 coulons to the address space, leaving everything else the fuck alone.
If we are honest, nobody really wants IPv6 for any reason other than "we are running out of addresses". The only interest served by making every computer directly and individually addressable on the internet is hackers,if we are totally honest about it. Nobody else actually wants IPv6, which is why the adoption is moving with the speed of a kneecapped sloth.
Adding an extra 2 coulons to the address space boosts the address space from IPv4's 254*254*254*254= 4,162,314,256 addresses (four billion, one hundred sixty-two million, three hundred fourteen thousand, two hundred fifty-six addresses)
to 254*254*254*254*254*254 = 268,535,866,540,096 (two hundred sixty-eight trillion, five hundred thirty-five billion, eight hundred sixty-six million, five hundred forty thousand, ninety-six addresses)
Perfect? Nope. It'd no doubt annoy the architect level types for being a kludge. But good enough? Yep. It gives everybody alive on earth several hundred thousand addresses each which is enough for the forseeable future.
Implemented easily? Yes. Ok, it requires a massive rewrite of networking code on the same scale as IPv6. But nobody needs to actually learn anything new to use it because everybody who knows IPv4 carries their entire knowledge and skillset over to it intact and can just carry on using it. So as soon as equipment is available it's going to be able to be used as default without any problem whatsoever as it's basically "no change" for all intents and purposes.
"If everybody did that, the honest answer for that IPv7 would probably be IPv4 with the addition of an extra 2 coulons to the address space, leaving everything else the fuck alone."
That's the most sensible comment in this thread, and is an engineering solution that solves the problem at hand. No added BS just for the sake of goldplating things. Trouble is, protocols are designed by committees, with each member wanting an input.
There's also the serious security issue when every device on the net must have unique worldwide identifier, rather than being behind nat, which again was an engineering solution designed to solve a particular problem. IPV6 is disabled in everything here, and even removed from kernel rebuild options...
You may want to have a look at the following a proposal, EzIP (phonetic for Easy IPv4) that we submitted to IETF:
https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03
The EzIP utilizes the original IPv4 protocol standard RFC791 and the long-reserved yet hardly-used 240/4 address block to expand the IPv4 pool by 256M fold.
Basically, this approach will not only resolve IPv4 address shortage issues, but also largely mitigate the root cause to cyber security vulnerabilities, plus open up new possibilities for the Internet, all within the confines of the IPv4 domain. In fact, this scheme even may be deployed "stealthily" for isolated regions where needed.
Abe (2018-07-19 22:29)
Our study now indicates that there is practically no more shortage of IPv4 address, let alone going through the trouble to deploy IPv6.
Since EzIP can multiply each public IPv4 address by 256M (Million) fold without affecting current equipment, this enables over 75% of nations to serve their respective countries starting from just one IPv4 address that is already assigned to that nation. This is in addition to the current Internet services.
Essentially, the CIR (Country-based Internet Registry) model utilizing IPv6 proposed by ITU-T a few years ago can now be stealthily implemented under IPv4, even without forming the sixth RIR at all. With two styles of operation disciplines and conventions, the consumer will have truly two options to choose from.
Thoughts and comments would be much appreciated.
Abe (2018-08-18 22:15)
I run a few low-traffic sites and find that the bots that visit are invariably IPv4. I do get traffic from what appears to be phones on IPv6, and a sprinkling of others. Because I have IPv6 set up on the home network here, I find that it will often access the rest of the world using IPv6 if the far end offers it.
That's the other side of the coin of course, your average punter just connects his router to the cable modem (or uses a smart cable modem that does both jobs). If that magically broadcasts the IPv6 magic on the local network then most modern devices will set up and use it and said punter will be none the wiser for it. If he's got to go into a configuration menu and tick a box somewhere then all bets are off.
I run a website which mainly serves the Indonesian market. We see a lot of traffic coming over IPv6. I don't have any real insight into whether ISPs in Indonesia are running up against IPv4 address limits and so choose to issue IPv6 addresses, we just run dual stack and a lot of people there use IPv6.
And your target demographic? Lemme guess, cat videos. Auntie Mabel reading her e-mail wouldn't know an IPv6 from an IP Freely.
For the rest of us, there's IPv6 or CG-NAT. The choice is yours but don't come crying to me when you can't run a simple e-mail server on your endpoint because it's behind multiple layers of unpredictable NAT and the incumbents have you stitched up like a kipper. Want your own domain? Want to access that NAS from the wider 'net? Need to run a VPN? KER-friggin'-CHING!
Follow the money, son. YKIMS.
"An IPv6-only mail server is not likely to be able to receive mail from most of the world, so what's the difference?"
EHORSECARTORDER
If IPv6 were widely deployed, this would be a non-issue. Using it as an excuse not to deploy is a self-fulfilling prophecy.
Have you lot all got secret stacks of /16s that you want to (ugh!) "monetise" in the near future, or what?
Especially when Reg is behind Cloudflare. Cloudflare make it as simple as ticking a box to enable IPv6.
You're half right. Enabling IPv6 on Cloudflare is indeed a flick of a button. Unfortunately there are still a few internal systems which wouldn't work when clients start sending them requests using an IPv6 address. In fact, we _had_ it enabled "for testing" on the old channelregister.co.uk site, and that showed us we had a lot of things to fix before we could enable it on thereg also.
We have a branch which purportedly fixes everything IPv6 related on our systems, and I'm now in a position to properly test it.
So, Soon®
4G telephony has IPv6 support as a requirement.
DOCSIS 3 has IPv6 support as a requirement.
Google sees 20+% of its users come over IPv6.
https://www.google.com/intl/en/ipv6/statistics.html
Just because YOU don't see very many doesn't mean that most people's phones don't, by default, go via IPv6 without anyone even knowing. Maybe not when they're on your home wifi, but when they are mobile they do.
Has huge parallels with GDPR.
We've all known it's been coming for two years, but when did you get your please-please-can-we-keep-spamming-you emails? In a steady trickle over those last two years, or all in a mad rush in the last week or so?
All working now? Crisis in the future? Nah, it's all working now, we'll deal with it later.
I tried to use IPv6 about 2-3 years ago. My ISP at the time was on the leading edge of IPv6 support. However, many websites did not support it, and the fallback to IPv4 caused a performance decrease. It broke a few services in ways that were obscure, difficult to diagnose, and possibly unfixable. After some weeks, I turned it off.
I tried to use IPv6 again on my new ISP this year. And... it's not supported. I'm behind IPv4 carrier NAT.
"However, many websites did not support it, and the fallback to IPv4 caused a performance decrease."
That makes *0* sense. If the website didn't support it, there would be no AAAA record in the DNS reply, and so IPv6 would never be attempted in the first place.
Now if the site is publishing AAAA records and yet their IPv6 connectivity was broken, THAT would cause issues (although less so these days with "Happy Eyeballs" in most browsers). In that case, they really should either fix their connectivity or unpublish the AAAA records.
That makes *0* sense. If the website didn't support it, there would be no AAAA record in the DNS reply, and so IPv6 would never be attempted in the first place.
Technically, you'd still see a small increase in perceived time to first byte as you'd have a second round trip to your DNS server to fetch the A records. But I'm just splitting hairs, because if that's noticeable you probably want to be thinking about using a better performing recursor.
"...All working now? Crisis in the future? Nah, it's all working now, we'll deal with it later..."
On the plus side this attitude keeps me in work.
On the down side, the number of times I'm faced with legacy systems that were pushed to be dealt with in the future....and now is the future and the options are slim to none, is increasingly frustrating.
But then again...I like to eat :)
There is a limit to the number of IP versions it is possible to issue and still run on the same hardware (eg Ethernet switches). It's 16.
The version number is contained in the header of every single correctly formed IP packet.
So skipping/wasting a number or two is not something you really want to do.
"So skipping/wasting a number or two is not something you really want to do."
If IPv6 is inherently unsaleable - which the article seems to be pointing to - that number is already wasted and skipping it doesn't cost more. The important thing would be to take a good deal more care next time around.
"Does it really matter if we live in a 25 percent IPv6 / 75 per cent IPv4 world?"
Maybe not, but there is another possibility: we could have reached peak IPv6. The proportion of IPv6 could start to decline if IPv4-only networks grow faster than those with IPv4+IPv6. At that point, the people who held back from IPv6 deployment will smile smugly as they say "I told you so", and the decline becomes self-reinforcing.
This is not great for society - scarcity of IPv4 addresses entrenches the market power of the existing big players. Which, erm, makes it rather likely that the big players would like it to play out this way after all.
Now, I imagine Google + Facebook between them have enough clout to ensure that IPv6 remains in some form rather than vanishing entirely, and indeed they probably quite like running their own private Internet, but there is a risk it could become increasingly irrelevant.
At that point it's back to the drawing board. IETF: please make a way to *extend* the address space of the Internet incrementally, not replace the Internet with a new one running alongside it.
If not, then sooner or later someone is going to propose a 64-bit port number option for TCP and UDP. When that happens, NAT is entrenched forever.
> How, exactly? Invent some more numbers?
Options might include:
* An IPv4 address extension header. When a client talks to a server which doesn't support the address extension option then it would fall back to stateful PAT.
That's the sort of approach which should have been taken in the first place.
If instead we want to complete the IPv6 transition:
* A comprehensive, global NAT64 infrastructure is put into place. It could be hosted by the existing CDNs (e.g. Akamai, Cloudflare, Google), and would treat the whole IPv4 Internet as a pool of content to be served to IPv6-only clients. It would be run as a public service, like public DNS resolvers.
Access providers could then start providing IPv6-only connections, releasing the chokepoint of IPv4 supply at client side.
As usage ramps up, content providers have an incentive to make their content available via IPv6: (a) to get better logs, (b) to serve content faster to this increasing pool of IPv6-only users.
Neither my major UK or ES ISP has offered it to me.
I've now made do with my (business, mind you!) ISP not giving IPv6 addresses by using a FRITZ!Box router, and telling it to establish the connection for, and route internally, the IPv6 /48 that Hurricane Electric nicely gives pretty much anybody that asks them.
Sure, it's not native - but it's better than not having any IPv6 connection at all.
I work at U of Arizona (arizona.edu, class B). I asked our IT about IPv6 and was told they would use it more if anyone cared but there is no demand and no need. Everything within campus uses 10-dot and everyone outside comes in via VPN. They only use IPv4 for web-facing services and they have plenty for those. So it boils down to "if it ain't broke, don't fix it".
The monkeys pounding keyboards to write consumer firewall software haven't stumbled on to a working IPv6 version yet. My AT&T router needs a strange set of firewall options to even marginally pass IPv6. I found those options by brute-force trial and error while watching packet captures. If I hadn't been in a good mood at the time, I might have thrown the router and a panicking Mac Mini Server into a wood chipper. Or used IPv4. Not sure, really.
In theory it shouldn't need anything in the router apart from understanding IPv6, broadcasting the relevant magic to the local network and establishing a default route to the outside. The equivalent of the NAT 'firewall' that you get for free with IPv4 is the fact that the router firewall should be configured to drop any packets not associated with a connection set up by the local network. That stops all bad stuff coming in unless the user explicitly configures a rule. It's on a par with doing port forwarding under NAT with no other restrictions in place (so internal users can talk to any external address and port).
I find OpenWRT to be just fine for this stuff, although admittedly it's not consumer software (but that style of port-opening interface could be).
Hmmm... I connect via AT&T Uverse at home. I've had IPv6 for at least two years now. I didn't have to do anything to get IPv6; they remote-upgraded the modem/router/wireless/tv thing's firmware early one Sunday morning, and on rebooting the device I had IPv6. Since then they've sent out a new modem/router/wireless/tv thing (black instead of silver) which had IPv6 running from the start. I've got a Mac mini running Snow Leopard Server (the last of the real server systems from Apple) and a homebrew Winbox running WinServer 2012 R2, upgraded from 2012, upgraded from 2008 R2, all WinServer versions free courtesy of Microsoft Dreamspark/Imagine/whatever-it's-called-now. DNS and DHCP are on the Mac, AD is on the WinServer (yes, I'm running AD at home. Doesn't everyone?) and have had no problems.
"The monkeys pounding keyboards to write consumer firewall software haven't stumbled on to a working IPv6 version yet."
Shorewall6, the IPv6 version of Shorewall, works fine. Has done for a while. It's open source, and maybe not consumer friendly, but I'm not your ordinary consumer, so it works for me.
I'm in the lucky position where my ISP has rolled out IPV6 providing
a) You don't use their modem
b) You set up access using a method they don't support or document on their website, and support don't know about
c) You happen to be connected to a recently updated RIM that has a very specific piece of hardware and configuration
If you do that, you can happily use IPV6 and derive the benefits of using the IPV6 routes that no one else is using because it's become "first slaughter the right number of chickens", and suddenly find yourself with next to no congestion.
@kitschamp
Congestion is not caused by using ipv4 or relieved by using IPv6, congestion is congestion. IPv6 is like driving a Tesla on the motorway/highway when everyone around you is in ice car. You can only get so far in a Tesla and have to go to special places to charge it whilst facilities for internal combustion engine cars are widespread and you can go anywhere the road goes. If your in your Tesla stuck in a jam with ice cars it’s the same experience as with IPv6 effectively the transport infrastructure is busy despite the mode/addressing scheme used for transport.
My international links are constantly and consistantly better over IPv6 - often due to different network routes being used, but even that's not always the reason.
I ran this just now, in parallel - Swansea, UK to Sydney, AU - often the difference is better than this:
--- catmint.dyslexicfish.net ping6 statistics ---
562 packets transmitted, 562 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 293.132/296.183/330.526/4.885 ms
--- catmint.dyslexicfish.net ping statistics ---
565 packets transmitted, 565 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 298.804/301.995/343.655/4.852 ms
> Congestion is not caused by using ipv4 or relieved by using IPv6
All else being equal, that should be true. But if @kitschamp's ISP's routers are overburdened by traffic which happens to be >99% IPv4, it's perfectly plausible for the same routers' v6 stacks to perform better.
Internode was one of the first to offer IPv6 in Australia, and are (or used to be) a very geek friendly ISP. Letting you run servers from home on retail connections, etc. That's who I'm with, and IPv6 is working fine for me. And they are generous with it, I think I have enough IPv6 for every single molecule in my entire home. Well, maybe not those hard to reach ones under the 'fridge. The cockroaches living there will just have to put up with NAT, or move next door, it's smaller.
As we are talking about going full Serbian Ultimatums with freedom fries on the side, the US should demand that Iran hand in all its IPv4 blocks lest hard sanctions become harder, possibly the harderest ever.
I'm sure this will give us a couple of additional years.
Just tell the Orange personality that the FBI's using IPv4 to spy on him, and make sure Nunes hears it too and the solution is to switch to IPv6 because the FBI can't spy on it, and that Putin likes it. Get it on Fox and Friends and it'll happen in very short order.
If you're on Linux, add the 'privext 2' option to your interfaces(5) file for any network interface that will have an IPv6 address. This makes the MAC-based address local in scope, so it won't appear over the net. Addresses derived from MAC addresses are also easy to block at your router since they follow a standard pattern (with ff:fe stuck in the middle), so even if you misconfigure some machines, they won't be allowed to leak their MAC address to the outside.
That's only when using stateless autoconfig (SLACC), not when using static or stateful autoconfig (DHCPv6). Most OSs default to using privacy extensions when SLACC is in play (eg, outbound connections use a 2nd temporary and random IP that changes).
So no, no privacy issue.
That's only when using stateless autoconfig (SLACC), not when using static or stateful autoconfig (DHCPv6). Most OSs default to using privacy extensions when SLACC is in play (eg, outbound connections use a 2nd temporary and random IP that changes).
Oh well, if it's that easy it's a real surprise that no-one is doing it.
Protocols with insecure defaults or options always seem to end up getting exploited. Take SSL/TLS for example. Not good enough. Back to the drawing board!
I agree. Get rid of SLAAC and leave IPv6 without it, it's perfect then. No need to arse around "redoing" IP6 itself as you are implying.
Does the standard still call for the mac address to be included in the packet? Maybe that's why nobody wants it?
Whilst what you are describing would literally be true in some cases, the case you describe is actually when the MAC is incorporated as part of the hosts IP adddress. - There is no "MAC field" in an IP packet.
Someone had this bright idea to say that a local lan has to be at least 64 bits wide, so that any host can guarantee itself a unique IP address without needing to use DHCP6 - simply by setting the 64 bits to contain the MAC address, and the rest of the address set to the subnet address.
Ugly, horrible, stupid. What happens if someone intentionally manually sets their IP to match what yours should be? There are many other ways to do it (e.g. DHCP6 which - as its name suggests - is the IP6 version of IP4)
So, it only applied to stateless IP configuration - there was never any such leakage if you just apply a normal address statically.
This is my only criticism of IP6, and it turns out to be administrative rather than technical (if you ignore statless addressing (SLAAC) as a requirement)
In my opinion, this basically wastes 56bits - meaning they could have just as well made IPv6 72 bits instead of 128.
Anyway, sod that. SLAAC will never exist on anything I control if I have any say in the matter. If I have 2 neighbouring IP6 lans, I'll be buggerred if I'm going to apply for a second /64 and if It's a "router -> WAN <-> router" setup, it will be a /126 - far easier and more efficient.
> SLAAC will never exist on anything I control if I have any say in the matter
Then you're not using any Android devices, which still doesn't support DHCP6
I agree that SLAAC sucks, but there is one valid use case: on home networks with dynamic addressing. If the line drops and reconnects, you need to renumber your devices very quickly, which would mean extremely short lease times if using DHCP6.
Now you say, surely IPv6 has enough address space to give everyone a static allocation? It certainly does, but dynamic addressing is not due to shortage of address space: it's due to route aggregation.
When a user disconnects and reconnects, their session may terminate on a different BRAS. To avoid route flaps in the ISP's core network, the subscriber gets an address out of a larger pool which is routed to each BRAS. So if you change your BRAS, you must get a different address.
For business customers who require static addresses then usually this involves L2TP tunnelling the session to another BRAS. This makes providing static IP services more expensive (additional equipment).
SLAAC will never exist on anything I control if I have any say in the matterThen you're not using any Android devices, which still doesn't support DHCP6
I use IP6 on all my android devices, but then i statically configure the IP from start-up scripts (by the way, has anyone had issues with android 5+ routing ip6 tcp off lan? udp6 seems to work, i can't get tcp6 to work on the newer boxes I run)
But yeah, if android over ip6 has to be supported now, and it doesn't support dhcp6 then i guess you're right.. Up to now, though, all androids I've seen have been IP4 only from the 'consumer' side of things.
I agree that SLAAC sucks, but there is one valid use case: on home networks with dynamic addressing. If the line drops and reconnects, you need to renumber your devices very quickly, which would mean extremely short lease times if using DHCP6.
Now you say, surely IPv6 has enough address space to give everyone a static allocation? It certainly does, but dynamic addressing is not due to shortage of address space: it's due to route aggregation.
I realise many ISPs will still give out dynamic Ip6 prefixes when they start doing ip6... But you make a good point regarding the renumbering... I hadn't thought of that.... A "cost" of not using NAT! You could always use NAT6 <gets coat> :-)
How would slaac help though? Surely in either situation a machine needs to repoll for its new IP, or have it pushed.. It surely would be the same for a dhcp'd or slacc'ed host to realise its ip was no longer valid, and need to be updates?
From what I can tell, all the major infrastructure is in place for IPv6. All the service providers I have looked at with regards to computing resources support v6, just consumer networks that don't.
I am with Zen, and their network has full dual stack support, and the router they provide for free to fibre customers is not only top-notch with regards to performance and features, but it also has full IPv6 capability with a couple of button presses without any faff. I don't understand how it is so hard for the mainstream ISPs to produce CPE that does the same!
"The existence of IPv6 is largely non-existent in the consumer's mind when it comes to making that decision"
It isn't a factor in my mind at all. Behind my router, I'm entirely IPV4 and will likely stay that way for a very, very long time (there's literally no reason to change this in my LAN), so the only thing IPV6 affects is the configuration of my router. As a result, I don't care whether or not my internet connection is IPV6. I'm good to go either way.
It is indeed! That's why my comment is littered with "I", "my", and so forth. I was just explaining why whether or not a piece of equipment or service supports IPv6 doesn't enter into my purchasing decisions.
Other people may have different needs and therefore different requirements.
"What's the benefit of that?"
I can think of one use case off the top of my head, but only coz it's something I've had to deal with. Running an OpenSim server behind NAT sucks, especially if you are not a network expert. On the other hand, I'm not so sure OpenSim supports IPv6.
In no particular order;
1. Usability sucks
2. Massive capex required to replace incompatible kit
3. No real business case, when everything is sitting behind a thumping big NAT / NetScaler.
4. The additional cost of making sure every wheezing business app is IPV6 compliant
5. The cost of MAKING all those wheezing old business apps IPV6 compliant.
6. General business inertia to resist change, and avoid risk.
"1. Usability sucks"
Not true. Was maybe true 15 years ago.
"2. Massive capex required to replace incompatible kit"
Not true. You'll get IPv6 when you next update your kit anyway. That's why the preferred deployment is dual-stack, so you can run IPv4 as long as necessary.
"3. No real business case, when everything is sitting behind a thumping big NAT / NetScaler."
That depends very much on your scenario. But there's no urgency; just lie back and let it happen, which doesn't need a business case.
"4. The additional cost of making sure every wheezing business app is IPV6 compliant"
That's a real issue if you're at a point where you can't update those apps.
"5. The cost of MAKING all those wheezing old business apps IPV6 compliant."
That's #4 again.
"6. General business inertia to resist change, and avoid risk."
That's true. Dinosaurs go extinct for that reason.
"1. Usability sucks"
Not true. Was maybe true 15 years ago.
"2. Massive capex required to replace incompatible kit"
Not true. You'll get IPv6 when you next update your kit anyway. That's why the preferred deployment is dual-stack, so you can run IPv4 as long as necessary.
Don't scare them with facts - when it comes to Ipv6, for some reason there are a bunch of detractors here who downvote without commenting, or provide no legitimate argument against it.
They just hate what they don't understand.
They are like the fox news/republicans of IPv6
downvote-baby-downvote!
3. No real business case, when everything is sitting behind a thumping big NAT / NetScaler.
4. The additional cost of making sure every wheezing business app is IPV6 compliant
Sorry, but if 3 is true, then 4 is a lie.
Because if you're behind NAT, only your gateway need be IPv6-capable. It's providing the service to others (quite literally translating the network addresses!).
So your creaky old business apps don't need to change one iota. At worst, the gateway will still send them out via IPv4.
But if you IPv6 JUST THE GATEWAY, you're golden. Done. No further changes required. IPv6 access now and in the future, and billions of addresses to use internally.
The whole IPv6 / NAT argument has ALWAYS BEEN horsecrud.
I think the reason IPV6 isn't being adopted fast enough for the observers is that networking is irritatingly complex even under IPV4. Equipment needs to interoperate using a large set of agreed frameworks, and all of them need to work. Therefore, once some system has it working under IPV4, the general sentiment tends to be "not again". Other than running out of address space, I can't see much of an incentive for most groups to go to the effort to switch.
This has been my experience--I'm not against IPV6, but I know that if all systems were to switch to it, I would start getting calls from my family and friends to come and fix things, and most of the time, I don't know how to fix things with major networking problems such as this. My main experience hasn't been with networking, so even when I get a shell on some piece of embedded Linux-based thing someone bought, I'm not sure how to turn the access I now have into a functioning device. There is only so much turnover so that we can just say "throw it away and get one that has been updated". Usually, that's not a good answer.
Yes, the main issue is IPv6 was designed "too early", when the landscape was quite different, when SOHO and true home LANs were almost unheard of, and most networks were carefully look after by skilled pros.
IPv6 is quite "unfriendly" for the casual network admin. Consumer network devices should have better management tools to take care of it, and "shield" most consumers users from the complexity, they can't handle it just like IPv4 just with longer and cumbersome hex addresses to type and use.
Yes, you can still use IPv6 at the external interface only, and keep on NATting it to internal IPv4 addresses and remove much of the complexity (albeit with the same issues of NAT for some protocols), but that's not what the industry want, I guess, especially since they see a delicious opportunity to track each single device on the internet.
"but that's not what the industry want, I guess, especially since they see a delicious opportunity to track each single device on the internet."
I hadn't thought of that aspect.
If I ever shift my LAN to IPv6 (I don't know why I would, but just for the sake of argument), my LAN would still go through a router doing NAT, specifically so that my entire LAN only presents a single IP address to the rest of the world.
The less the world can tell about my network configuration, the better.
Why did they have to completely redesign the protocol for IPv6? All that we needed was a few more bits for the address fields. There's nothing wrong with NAT routers and the inherent security bonus everyone receives from having to know at least a little about what they're doing before opening a huge security hole into a home or office.
Instead with IPv6 we have wacky huge address fields, massive /64 allocations to small businesses as standard, a complete rethink about how IP 'should' be done, and funnily enough no-one wants to bother implementing it on their network. Who'd have thought it?
"Why did they have to completely redesign the protocol for IPv6?"
As often discussed here: IPv4 has no repeat no mechanism for indicating a different address length, so switching to a new IP version number was obligatory. And (in 1994 when these decisions were taken) there were a lot of known gotchas in IPv4, so IPv6 was redesigned to avoid them. Now, of course, there are workarounds for those gotchas, so people don't notice them so much.
As often discussed here: IPv4 has no repeat no mechanism for indicating a different address length, so switching to a new IP version number was obligatory.
That's not what was suggested.
Consider a crude 'upgrade' model to an imagined IPvX:
Keep the IPv4 header as-is.
Steal part of the data field to hold a header extension with new 64-bit addresses (and other stuff if required)
Define a "magic" IPv4 address which indicates that the "real" extended IPvX addresses are at the start (or end) of the data field.
A true dual-stack IPv4/IPvX device would read the address in the header, and either route the packet as IPv4 from an old device or understand the "magic" address and retrieve the real addresses for correct IPvX routing.
An old IPv4-only device would see the packet as an IPv4 one and dumbly route it to the "magic" destination, which would be an IPv4/IPvX gateway able to send it on it's way and process replies.
It's an ugly, crude, NAT-style hack, but could offer an upgrade path to a later IPvX+1 format once IPv4-only devices had gone away.
> Define a "magic" IPv4 address which indicates that the "real" extended IPvX addresses are at the start (or end) of the data field.
You can use one of the special reserved ranges at the top end, e.g. 299/8 routed to gateway for 299/8 which converts 299.a.b.c to 299.a.b.c.d.e using a couple of bytes stuffed somewhere in the packet and there you have your big range expansion and it works with everything you still have.
It would either work brilliantly or fail horribly or just kick everything further down the road to an even bigger non-catastrophe.
.
p.s. "299", a fiendishly cunning distraction disguised as a gift to the pedants
Steal part of the data field to hold a header extension with new 64-bit addresses (and other stuff if required)Define a "magic" IPv4 address which indicates that the "real" extended IPvX addresses are at the start (or end) of the data field.
A true dual-stack IPv4/IPvX device would read the address in the header, and either route the packet as IPv4 from an old device or understand the "magic" address and retrieve the real addresses for correct IPvX routing.
In others words a (presumably transitional but not necessarily) gateway between OLD protocol, and NEW protocol, not a 'compatible protocol'.
Well, we now have the NEW protocol in IPv6 (though "new" is only relatively speaking) - nothing stopping you or anyone else writing the gateway you describe - at least, nothing that any "different IPvX" could solve.
The local stack would need to be altered... unless you just ran the conversion on your edge router... and then.... you've just designed a new form of IPv6 over IPv4 tunnel!
Incidentally, your proposal is basically the same as the already existing 6to4 scheme (not to be confused with the more traditional manually configured tunnel, 6in4)
In others words a (presumably transitional but not necessarily) gateway between OLD protocol, and NEW protocol, not a 'compatible protocol'.
Not really. You need to think of both the endpoints, and the network.
For the endpoints I agree, this is little different to an IPv4/v6 situation. No IPv4 system can communicate directly with an IPv6-only one, since it has no way to address messages to it, and the same would be true of IPv4/IPvX, but that's of little significance. Most new systems, at least for some time, would be dual-stack.
The big problem is the network side. Drop an IPv6 system into a pure IPv4 network, and it can't talk to anything. Same is true for an IPv6 subnet whose only external connections are pure IPv4. Unless someone configures gateways or tunnels on the networks you'll remain as an island.
Of course, the IPv6 experts will say that such tunnels are easy to setup, but that's not the point. Someone needs to set them up, configure them, identify peers on all the networks they need to tunnel to, etc. That's why IPv6 hasn't taken off, no-one wants tto do that for every single network they talk to.
If IPv6 had been designed so that its packets could have been processed by IPv4 hosts, even if that 'processing' just meant tossing them to some catchall address with a "hey, you deal with it" tag, it would have been much simpler to setup interworking. A few catchall systems, setup by ISPs, could have been adequate. I could have plugged an IPv6 system into my home IPv4-only network and it could still have got messages to any IPv6 system, albeit in a roundabout way. Make upgrading that simple, and far more people would be running IPv6 now. Eventually those catchall routers would be obsolete and would fade away. Instead, people prefer NAT for the same reason, it works that easily and requires negligeable setup.
> Incidentally, your proposal is basically the same as the already existing 6to4 scheme (not to be confused with the more traditional manually configured tunnel, 6in4)
You have highlighted why people look at the "upgrade" path and decide it isn't worth the annoyance/uncertainty it until it becomes necessary. The fact that there needs to be a "not to be confused with" caveat is not good and the "already existing" was made up after the fact as a bodge, not as part of an intended thought-out path.
Useful recommendations were non-existent in the beginning and are still badly vague. When I read a how-to guide I want something with a clear path to a successful result, not a fucking "choose your own adventure" book.
/"299" AC
Hindsight is such a great thing…
Lots of the internet protocols have had trouble doing necessary updates because some of this stuff is hard™ and requirements have changed. It's a tribute to the quality of the original work that they're still in place and generally doing such a good job but you only have to look at the problems of securing e-mail transport (known for years to be a leaky sieve) to appreciate the difficulties of trying to maintain compatibility while introducing improvements. Sometimes you can't do both.
IPv6, like http/2, isn't perfect but it is in many ways an improvement over what we have.
In the early 1990s it could make sense, you had the Internet, a relatively few company/uni networks, and all the other relatively few users just connected via telephone line modems, mostly using a single device, so backward compatibility and simplicity outside professional users looked not much of a issue.
Everything was "trusted". Nobody was collecting your data to make money.
Had been it adopted back then quickly, what is the actual internet would have grown around it, and found solutions for its shortcomings, without any compatibility and upgrade issues - instead it grew around IPv4, networks (and their enabling devices) proliferated, and users became billions plus other billions of devices.
So we got the actual situation. Maybe, had it been designed later, it would have been different. But now I don't think anybody is willingly to design another one, and like it or not, it has to be adopted soon.
Just, solutions are needed to cope with a design which is almost a quarter of a century old, and couldn't take into account what the internet is today.
Why did they have to completely redesign the protocol for IPv6? All that we needed was a few more bits for the address fields
Well, for a starter, adding a few extra bits (bytes) to the address field will break things. If you're going to break things, it's better to engineer something new and completely incompatible rather than just using a sticking plaster approach.
before opening a huge security hole into a home or office
NAT is not security, especially given that uPNP NAT traversal exists. Also, you're not going to run IPv6 without firewall rules on your router, are you? And anyway, I'd wager that most security problems don't come from attacks from outside the network but from numpties inside it.
Instead with IPv6 we have wacky huge address fields
Which, if (as you should) you assign addresses randomly, improves your protection against network mapping and hence port scanning, even if you do accidentally forget to do ingress filtering. You can't scan what you can't find, and /64 is plenty big of a space to hide a few hundred machines in.
massive /64 allocations to small businesses as standard
A /64 allocation is for a LAN. Actual allocations to businesses would be larger, like a /48, so you can have up to 65535 LANs.
Why did they have to completely redesign the protocol for IPv6?
Coming back to the first point, although I'm not sure about how well this works right now, IPv6 also has features for device mobility. So new protocols open up the possibility of new ways of working.
"Which, if (as you should) you assign addresses randomly, improves your protection against network mapping and hence port scanning, even if you do accidentally forget to do ingress filtering."
This implies that the LAN owner has to do stuff. For a large enterprise this is fair enough - they can pay for people to do it* - but for small businesses and home users it's a no-no. Unless the whole thing comes configured with such sensible default options it's going to be addressed along the lines of "what we have works - don't need anything else".
* and, in theory, to be trained if they're not already equipped with the knowledge although enterprises tend to treat this as optional, default off.
@ZeroSum: "No ISP charges for IPv6. Customers will not pay for as it."
OK, there isn't a separate item "IPv6", with an item cost, it is part of service package, and only the top level package includes IPv6. For example, I got this answer from one local ISP in Dec 2016 (contract length 24 months, I'll be shopping around at the end of this year again):
"For your information, the broadband service that we currently can provide is IPv4 and there is no planning for migrating IPv6.
By the way, we can provide Secure DIA Premium Always on service (using IPv4) which is able to support IPv6."
There are 3 levels of service package, the monthly pricing I was offered:
Broadband
4M/4M, 8 fixed IPv4 addresses HK$698
1G/1G, 1 fixed IPv4 address (free O365 license, laser printer) HK$648
Secure DIA Always on
(no quote)
Secure DIA Premium Always on
10M/10M 16 fixed IPv4 addresses, IPv6 HK$3500
20M/20M 16 fixed IPv4 addresses, IPv6 HK$4300
30M/30M 16 fixed IPv4 addresses, IPv6 HK$4600
The DIA services include guaranteed international bandwidth, mean-time-to-repair, proactive fault management and network management.
So do you think the infrastructure they have to support 1G broadband is not capable of supporting IPv6? If it is capable, they could roll out IPv6 at minimal cost. I conclude that they choose not to because, for them, squeezing the customers who really need it is more important that supporting the transition to IPv6. For me, IPv6 is a desirable feature, not a pay 5x as much essential requirement.
"NAT is NOT a security feature!"
True, but it can be used as an obfuscation feature, and that has some security value. I much prefer it if the world outside of my LAN only has a single IP address for it rather than having the IP address for each device on my LAN being exposed to the world.
So, IPv6 or no, I'll still be using NAT to accomplish this.
For the majority of home users, they don't need IPv6 (let alone want).
Consider the raison d'etre for IPv6; every device in the world (and then some) can have a unique, directly accessible public internet address, without the need to traverse NAT between private LANs and the limited pool of accessible IPv4 addresses.
But, does one actually want every one of one's devices directly accessible from the internet?
Methinks not. Security becomes a more complex issue, and the average punter barely understand security as it is.
So, for Jane and Joe Q Public who just want to get out to the internet, and don't give a rat's arse about running up a Web/FTP/whatever server at home, an IPv4 address delivered from their ISP via DHCP to their router, with everything home-side sitting behind NAT in private IPv4 space is all they need (and probably want). The ISPs can provide the infrastructure to bridge between the IPv4 addresses they assign to their clients' routers and the outside IPv6 world.
Those of us who do want to be able to get to our inner-net from the outer-net will want a static IP address. If we want/need to avoid the NAT-trap, then IPv6 is how we will need to go, and of course we'll need to ensure that only the devices we want externally visible will be accessible through whatever firewall and perimeter security devices we interpose between us and them.
For the average Joe (and even many organisations), not everything needs direct access from the internet, so private IPv4 addresses are more than adequate.
For the majority of home users, they don't need IPv6 (let alone want).
Speak for yourself because in many parts of the world there haven't been enough IPv4 addresses for years. It's infrastructure so people shouldn't really care whether it's IPv4 or IPv6, it should just work, but this pretty much does mean IPv6, with mandatory privacy extensions.
"Speak for yourself because in many parts of the world there haven't been enough IPv4 addresses for years."
SEP to be blunt.
"It's infrastructure so people shouldn't really care whether it's IPv4 or IPv6, it should just work, but this pretty much does mean IPv6, with mandatory privacy extensions."
The last two words say it all. Privacy extensions. Privacy isn't built in, it's an extension. What do we keep saying about security (or privacy)? It should be part of the original design and not an extension. If it isn't it's yet another thing to go wrong.
...has room for every grain of sand on earth.
When IPv6 was "invented" they needed a proper method of "transition" to the new way of things. As far as I know, this was never published. IETF is wonderful for standards and engineering, but the "transition" is a very political problem, and they really aren't good at it.
Of course, if Google only allows IPv6 connections sometime tomorrow, it could take place pretty quickly.
Oh, if spammers could be trapped by it as well, there might be another good case for it.
Of course they do. As long as IPV4 works without visible consequence, it will be used.
Only when things noticeably stop working will the rest of us grudgingly act.
The same happened with Netbeui and Windows networking. It was only when the internet became a thing and the visible consequence of using Netbeui was “no internet access for you” did small businesses make the effort to switch. Ditto to IPX on Novell networks.
First - the networking gurus who came out with IPv6 forgot (or they did it on purpose) to think of a method to insure cohabitation of IPv4 and IP v6 during the transition. Moving from one to another at once, in one single maintenance window is definitely impossible.
Second - it is very difficult, next to impossible to prove the cost+risk will translate in tangible benefits for the business.
I will ignore downvotes from home users and small business sysadmin warriors (I don't care if it works for your home network, good for you). Only opinions from serious technical people working for large/multinational companies with multi-platform, legacy, 24/7 business critical systems and solid change management processes will be considered.
I think there's good money to be made building IPv4 to IPv6 translation gateways. Let the Internet be IPv6 and make all the IPv4 address space private. I am aware that there are protocols that do not tolerate NAT and those developers who broke the internetworking rules with their applications should fix them. I'm sure there's money to be made by them too.
He's right. You want to learn IPv6, you take one look at those address representations and a set of crazy rules about address shortening and abandon it.
Those who plough on and get stuck in a wall of rubbish about auto assignment of addresses, translation services, IPsec, privacy concerns, something about your MAC address being your IP address and give up too.
These are real concerns, and most/all IPv6 proponents just dismiss them, as the second AC did, rather than address them.
Pray tell, how long did it take for you to find out that an IPv4's octets cannot be greater than 255? Or that a /31 is useless? IPv6 addresses are simply a string representation of 128 bits. IPv4 addresses are the same but 32 bits. If you can't read hex you really shouldn't be messing with stuff like this.
I suspect that's why the initial design called for embedding the MAC in the last 64 bits padded with ff:fe, since that forced you to think in hex and discover how simple it is. Obviously, this didn't work for everyone.
And, if you really want to memorise addresses, you can always go static. Your site prefix is 2a03:dead:beef::/48. Your router is on 2a03:dead:beef::1. Your LDAP&KRB5 primary is on 2a03:dead:beef::10 Your DNS boxen operate split-brain serving one set of AAAA and PTR (ip6.arpa) records and recursive service for 2a03:dead:beef::/48 and authoritative, if needed, for foreigners doing lookups on your ip6savvy.example domain. Your firewall blocks anything forwarded in/out on [2a03:dead:beef::]:137-139,445 and keeps a state table of all other traffic out, only letting requested packets back in unless there's a service running. Your workstation in mission control is on 2a03:dead:beef::1337. Eventually it becomes utterly mundane, boring and just as logical as IPv4.
Where is does fall down is all the maddening hoops, MTU settings, tunnel endpoint updates and protocol-breaking new packet types it takes¹ to actually get a sodding connection to the outside world, fending off detractors and nay-sayers while network access providers continue to argue, bitch and moan about how difficult it all is despite the fact that Murdoch's merry band of fraction-wits managed it right across their network without anyone ever noticing.
If IPv4 is so simple, without looking it up anywhere. give me the list of bogon, multicast, loopback and RFC1918 prefixes. No, seriously, I haven't checked my bogons list in a while...
¹ Actually, if you run OpenWRT with the SIT and luci-6in4 modules, it's a doddle. Whatever a doddle is.
Ok. This will get a bit of a reaction...
IP addresses are never going to be simple. They are big numbers. The same reason we don't memorize phone numbers for everyone and every takeaway we know means we won't memorize IPs for all the websites we visit or even all the systems we run. However, we do memorize some phone numbers, and some IP addresses. Because they are shorter and have fewer rules, the relevant IPV4 addresses are easier to memorize. 127.0.0.1 is localhost. 10.0.0.0-10.255.255.255, 192.168.0.0-192.168.255.255, and 172.16.0.0-172.31.255.255 are private space. I didn't have to look that up.
This has a certain level of convenience. I've been trying to get an openwrt device to make a range extender for a network, which I haven't done before and evidently it's not as easy as I thought. I've entered the address 192.168.8.1 a lot today, because that gets me to the shell. I've also entered the address 192.168.1.1 a lot, because that's the shell for the actual network. And sometimes, I have to disable DHCP on this device, meaning that I have to set my computer's IP manually. 192.168.8.2 is rather easy to enter. Like it or not, if I have to remember that the shell can be accessed at 29a0:37e9:0103:::382:011f:1, it will take me longer to figure this out and I will be more annoyed at the end.
In my mind, this isn't a reason to ditch IPV6. However, you can't deny (or actually I assume somebody can) that the addresses are easier. I can convert hex just fine, into binary, octal, and decimal. That's not the problem. The problem is that IPV6 requires me to memorize the whole number, which is a long number, whereas for IPV4, I basically only have to memorize "8". The 192.168 part never changes, and of course the network device is .1. For the same reason, I have memorized the IP of a site I use for ping tests. I never actually use the site or type the IP, but I can use my coincidental memorization of its address to say "Oh, DNS is working." I also know my personal VPS's IP address, although I definitely don't need it.
This is a legitimate, objective and reasonable concern. We could do with a bit of shorthand so, for example, if your VoIP ATA is on 2a03:dead:beef:1::1/64, ::1::1 would be easier to type and remember. Of course, this does sort of fall down when using SLAAC but things that have SSH running on 'em shouldn't be using SLAAC anyway.
I can't deny v4 addresses are easier. The reason I so vociferously support IPv6 is to preserve the fundamental equality of hosts connected to the 'net. Without that, it's not the Internet any more. We've run out of contiguous v4 space and none is going to magically appear from nowhere, not even from AFRINIC's meltdown. Unless v6 is at least tried, the Internet as we know it will cease to be and it'll become just another two-tier them'n'us system.
In summary, I give you Gary Feldman to play the theme tune.
Cameron Byrne in T-Mobile US even wrote the RFC on 464XLAT.
The individual or group theory of IPv6 adoption is undoubtedly the correct one. Until IPv6 is sufficiently ubiquitous or solves a problem (CGN bypass and in future 5G low latency) you will always find an individual or group that pushed it through their organisation
...from my pov:
To reach every site, or be reachable from every potential client, you need an IPV4 address. If you have an IPV4 address, you don't need an IPV6 address. Adding an IPV6 address is > 0 effort/cost/hassle/risk, so why bother.
Some actors have been too aggressive in pushing IPV6 by default, before it was (is?) sensible to use it. This leads to a "disable IPV6 and it works" mindset. And because there is generally no simple way to say "prefer IPV4", IPV6 gets nuked at the lowest level, never to be seen or herd of again.
people can remember IPv4 addresses and they understand the concept of subnets and NAT
I can count the number of people I know who know what an ip address on the finger of one hand. This is the very reason for DNS or we'd all still be entering ip addresses for e-mail and gopher! I don't even need a hand to count those who know about subnets or NAT.
20 years later and we are still struggling to gain widespread adoption. It’s looking a bit like DAB.
IPv6 has some major flaws, some of which have been addressed over the years, like the massive privacy fail we would have been exposed to by simply using the MAC address as the most significant bits of the address, would have permitted trivial tracking across internet connections. In IPv6’s inception it wasn’t a problem and IPv4 never had that problem.
IPv4 is mature, has loads of tools available, is well understood and has lots of security tools we can bolt on around it.
IPv6 is still immature due to its lack of use and lack of attention by hackers etc. While IPv4 has a lot of tools with skilled knowledgeable admins to secure it, IPv6 may have the tools but lacks the skilled knowledgeable admins.
After 20 years, we should be asking what we would design now and also ensure it would be backwards compatible to IPv4. Its not too late to redesign and come up with IPv8.
"the massive privacy fail we would have been exposed to by simply using the MAC address as the most significant bits of the address"
Yeah, that was crazy for a number of reasons. It would have totally broken the connectivity on most of my machines, since they randomize their MAC addresses on a regular basis.
Hey Kieran,
El Reg has been known to do some brilliant articles exploring the historical development of old technologies. How about doing something similar into graphs like the one at https://www.google.com/intl/en/ipv6/statistics.html?
For example it would be good to know why there is a drop off in uptake at the start of each year. How far back does the trend extend? Is it just budgets, or is it new year hangovers, or is it universities prepping kit for the next academic year, or what? You could offer some real insight and interest to your readers into a major process the industry is going through right now. Instead of throwing mud. Or maybe as well as throwing mud.
Incidentally, if you had published this article a month or two ago it would have seemed more accurate, but as it is now the IPv6 graph is ticking up again which undermines much of the speculation.
Well being not to up on Ivp6 I looked into it a bit more, and was surprised to see that it can also convey within an interface number of every interface on the planet.
I DON'T Want that thanks.
My router can do IVP6 and NAT to my interior IVP4 system without tunneling or other crap.
One of the things that makes us IPV4'ers suspicious is the religious fervour of the proponents. Especially if you utter "NAT", whereupon they will start waving garlic and crucifixes at you. The failure to realise that there are some valid uses for NAT, that should (instead of being deprecated in a "get-thee-behind-me-Satan" way) be first-class supported in any IPV4 replacement.
In short, if IPV6 did everything IPV4 did, plus some more, there would be much less fuss.
Just, I'm sure there are a lot of legacy IPv4-only hardware out there that manages critical or important tasks - and replacing it could be very expensive, and it will take years to upgrade it to IPv6.
I should get FTTH in a few months if not weeks - I'm curious about what they will offer.
> I'm all ears for your suggestion.
Suggestion as to how to get to the "universal deployment of IPv6" (in the infamous words of the IETF "Scotch BoF")?
Well - it depends if you think that's a worthwhile goal ;)
To my mind IPv6 is a sad case of "second system syndrome". It will probably get there in the end (all those addresses come in very handy for IoT, container networking etc.) but it has all been so much more painful than it needed to be - but alas it's too late now to do something better.
I'll happily concede that IPv4 makes censorship more difficult, as so many sites seem to be sharing the same IP. Any country trying to ban things has a bit of a headache on their hands, as Russia recently found out.
The bulk of the problem as I see it, are the companies that haven't got the resource to put behind training on IPv6 and have no impetus to do it. They don't want to break things. The colleagues in the industry that I've talked with, are majority opposed to IPv6 and don't want to budge. The business, won't drive it, because some management doesn't understand it and what it means. While we've got NAT, there's no internal pressure to make it happen.
So IPv6 being a worthwhile goal seems to be inverse to IPv4 being a pain in the proverbial A. People are more willing to find ways around the problems of IPv4, than get on and change to IPv6.
Honestly... the only way I see this change happening, is if IPv4 is formally discontinued, and the issue is forced. Otherwise, I can't see things moving forward much from here. Whether that's a good or bad thing, is up for debate.
IPv6 will be championed by the companies that want it or need it. For the rest it will probably require government legislation.
Here in Germany my understanding is that IPv6 is available from nearly all ISPs but, seeing as the majority of websites are IPv4 only, everything runs through a 6-to-4 tunnel anyway. Still, it means that the networks are ready for the rapid explosion in IP addresses that spy devices IoT will bring with it once every piece of kit we buy wants one.
My ISP (Plusnet) is IPv4 only.
I run a number of different IPv4 RFC 1918 subnets at home on different vLANs and/or WiFi SSIDs (as I used to for my work). I have a 'services' subnet for things like e-mail, LDAP (VM) servers, I have a 'Home Entertainments' subnet, a 'Guest' subnet (for visitors' phones etc) and a 'DMZ' for world accessible services like web, XMPP and IMAP. Part of the security of the set up is that servers in the DMZ can only reach the 'services' network through my pfsense firewall ruleset.
Sure I could turn on IPv6 for all this kit and I could use my Hurricane Electric IPv6 address block and assign routeable addresses to everything I need to - but unless I subnet my IPv6 block to mimic my internal IPv4 setup I effectively 'flatten' my carefully built multi-vLAN configuration. If I have to mimic the subnetting to achieve the same control over routing and packet filtering then there is little advantage to enabling IPv6 - apart from self-education and being ready to turn off IPv4 eventually...
As far as I can see, there are two ways way for a business network to move to IPv6:
1) subnet their address space to mimic IPv4 which seems like a lot of effort to achieve the status quo.
2) rip and replace.
There would have to be a major benefit to risk option 2 IMO.
Whatever you want (sorry - if you've now got an ear-worm).
"My ISP (Plusnet) is IPv4 only." I used to be with PlusNet and when I asked a few years back what their plans for IPv6 was, I was told "no plans".
I left. I also took the four office links to another ISP ... and around 30 odd of my customers ... and my dad and my brother and a few other family members and friends and acquaintances.
Not the end of the world for them, I'm sure.
.. a mate of mine designs networks for people, and recently I asked him how many IP v6 networks he'd deployed. 'Not one' was his answer.
At work here, I asked our head networks honcho when we were going to adopt IP v6. 'We dont need it' he said, 'we have a few externally facing IP addresses, we don't need more.' Internally we use 10.x.x.x of course.
Last MS course I did IP v6 got a brief overview,.... little more than an advertorial really, and I guess as part of the course was setting up Direct Access which uses ip v6, it was worth the overview, but ours runs in a 6to4 tunnel.
With each device IP easily available and quite statically assigned - and that's a PII, what about IPv6 and GDPR?
It does allow a user tracking far more advanced that that available with IPv4, when addresses could be re-assigned more often, and NAT at least shields internal devices and users to be easily tracked by address.
The problem is what devices will make available. If most routers won't implement NAT because IPv6 can work easily without, and that's what people get offered because also it fulfills the data hoarding disease most companies suffer of, the fact you could implement it creating your own router from scratch is almost irrelevant.
However good luck setting up IP6 NAT on a domestic router. The whole point of IP6 was to avoid the need for NAT.
They had to change how MAC worked on IP6 too because of privacy issues.
Security, Privacy, backwards compatibility and interworking all look like afterthoughts. Yes, my router and ISP support IP6, but I lose both firewall and NAT if I enable it and there are no sensible IP6 settings other than on/off.
A static IPv4 address is PII by the same logic. So no substantial difference in technology, it's just a question of implementation. Arguably IPv6 allows one to muddy the waters as to who is using which address, or set of addresses, because the address space is so very much more enormous.
If your company already has IPv4 internet facing addresses and is fully functional, why would you change? If you are a new company and setting up a new system, then IPv6 makes sense. So far as I can tell most of the tech needed to make them both coexist is in place and mostly working. Eventually most systems will become IPv6 but there will always be those that keep their IPv4.
It's much the same as in the WWW where almost all the desirable .com addresses are now gone, but other extensions have been added to increase the available options. Nobody has dropped their .com in favour of .biz and nobody will drop IPv4 in favour of IPv6 unless they have a reason to do so. So far as I can see there is no such reason.
I have IPv6 at home but not at work. I think this is the big drag factor in IPv6 deployment. Businesses.
Apart from slow players (looking at you Virgin and TalkTalk) Home users are gradually getting there.
Business in general, sees no real reason to implement something when they have no issues accessing all the Internet on IPv4 and aren't short of addresses in the v4 private ranges. Not until there is *some* degradation in the IPv4 experience will we see adoption of IPv6.
IPv6 isn't perfect, far from it. But it is deployable and is better than IPv4, but humans tend to be awful at just getting on with something when it's obvious is needs to happen but not that it has to happen right now (e.g. global warming).
I have just done a tiny bit of reading up on IPV6 - delayed because I don't research until I really need too. Could they have actually made it any more complex? It's akin to jumping from a 1950's car that is perfectly functional into some Dan Dare vehicle that is equally capable of queueing in a traffic jam down the Marylebone Road or nipping over to Alpha Centauri for lunch, via the Marianas Trench. This must have been defined by the committee normally responsible for creating tech European legislation. The fact that it's so hard to understand must have been a factor in the low uptake.
When I was first exposed to IPv6 on a cisco course my immediate reaction was that it's use of MAC addresses to generate the IP address was a security risk. Since then although some of the issues with IPv6 have been addressed my opinion remains IPv6 was designed to address the issues of the time and these are not the issues of today. I agree that IPv4 will need replacing but like a number of the other respondents I think we need to develop a new scheme that is suited to modern needs and concerns.
that a great deal of internet based technical innovation has been driven by grumble sites and advertisers.
Until the former changes, and the latter finds a way of merging data that it thinks it can glean from IPV4 addresses with IPV6 logs they wont change either.
The rest will come later.
I agree though that a lot of the change has been driven by individuals/groups rather than any kind of plan. Its difficult to see a revenue angle beyond Internet of Tat...
IPv6 was designed too many years ago where security wasn't a problem. Nobody today would dare connect anything directly to the Internet unless it was protected with a good firewall.
IPv4 forces you to use NAT, which in turn forces you to use your router's firewall. If something isn't working between your router and your device, you have no Internet connection or broken functionality (i.e. port isn't opened or being forwarded correctly) while you attempt to troubleshoot it. Which is a good thing. It fails closed. It is obvious something is wrong, and your device is protected while you troubleshoot the problem.
Anybody who's pro-IPv6 thinks using NAT with it is blasphemy. They will say NAT doesn't provide security and that you can still have a hardware firewall. But they won't mention that it's not immediately obvious if all of your devices are actually using it or if the firewall is configured correctly. Your devices could be directly connected to the Internet and you wouldn't know it because your device would be working fine -- until it was pwned. Which would probably be within 30 minutes....
Between that and the fact that IPv6 isn't backwards compatible, I don't think IPv6 will ever be widely adopted. It is a 20th century protocol and we are now in 2018. It's time to go back to the drawing board.
IPv6 always suffered from three problems:
1. The benefit of switching is largely to the community rather than to the adopter.
2. The lack of a migration plan.
3. Clever engineers thinking up more ways of improving IPv4 address space utilisation.
The "running out of IPv4 addresses" problem was always over-stated because it assumed that sparse utilisation of an address space would always be the norm because the allocation strategy has to be dominated by routing efficiency - doesn't it?
Technologies like MPLS have greatly increased the efficiency of address allocation and now LISP (RFC 6830) is providing a generalised model that allows global IP Addresses to be densely allocated to Hosts or Autonomous Systems while, at the same time, allowing a separate address space to be used for the underlying network - i.e. allocated with topological efficiency in mind.
LISP is IPv4/IPv6 agnostic and works with both. It's actually a good way of running IPv6 end to end over a corporate network that's still IPv4 based. Maybe some are starting to do that - keeping all their IPv4 kit (with a private address space) - but allowing for IPv6 externally - and hence distorting the stats.
However, that may just be the optimistic view. The point is that IPv4's 32-bit address space always could address all the atoms in the universe - it just couldn't also route efficiently to them. Now, with LISP it is possible to densely allocate the 32-bit address space while still having efficient routing.
If LISP had been around 25 years ago when IPv6 was proposed then I doubt whether IPv6 would have got enough support to have got off the ground.
Of course, we are where we are with a mixed equipage. However, it is now the case that if an organisation can't be bothered to move to IPv6 and already has enough IPv4 addresses for its own use (which most do if you can allocate them densely) then LISP gives a very good technical reason to avoid the move for anything other than externally facing systems.
LISP is now part of (e.g.) CISCO's product line and just maybe we are starting to see an impact from this.
I've been running IPv6 almost exclusively for a decade at home. I've been running IPv6 at work for about 5 years as well.
Let's assess a few of the real reasons for IPv6 not happening.
Security :
With IPv4, you get NAT which is like a firewall but accidentally. It's a collateral firewall :) The idea is that you can't receive incoming traffic unless it's in response to an initial outgoing packet which creates the translation. As such, IPv4 and NAT are generally a poor man's security solution which is amazingly effective. Of course opening ports through PAT can mess that up, but most people who do this generally don't have a real problem making this happen. With modern UPnP solutions to allow applications to open ports as needed at the router, it's even a little better. With Windows Firewall or the equivalent, it's quite safe to be on IPv4.
IPv6 by contrast makes every single device addressable. This means that inbound traffic is free to come as it pleases... leaving the entire end-point security to the user's PC which more often then not is vulnerable to attack. IPv6 can be made a little more secure using things like reflexive ACLs or making use of a good zone based firewalling solution, but with these options enabled, many of the so called benefits of one IP per device dissolve in these conditions.
No need for public addresses:
It's really a very small audience who needs public IP addresses. In the 1990's we had massive amounts of software written to use TCP as its based protocol and to target point to point communication requiring direct addressing. This is 2018, almost every application registers against a cloud based service through some REST API for presence. When two end points need to speak directly with one another, the server will communicate desired source and destination addresses and ports to each party and the clients will send initial packets to the given destinations from the specified sources to force the creation of a translation at the NAT device. Unless the two hosts are on the same ISP with the same CG-NAT device serving them both, this should work flawlessly. Otherwise, a sequence of different addresses will need to be tried to find the right combination to achieve firewall traversal.
In short, we no longer have a real dependency on IPv6 to provide public accessibility.
Network Load Balancers
20 years ago, only the most massive companies deployed load balancers. Certainly less than 1 in 100 would have hardware accelerated load balancers capable of processing layer-7 data and almost certainly none of them could accelerate SSL.
These days, there are multiple solutions to this problem. As such, a cloud service like Azure, Google Cloud or Amazon can serve hundreds of millions of websites from a few IP addresses located around the world.
File transfer services
No one copies files directly from one computer to another anymore. We don't setup shares and copy. We copy to a server and back down again or use sneaker net with large USB thumb drives. With DropBox, OneDrive, Box, etc... in addition, our largest files on our hard drives are cloud hosted anyway. So if we lose a copy, we just download it again.
I can go on... but we simply don't need IPv6 anymore. The only reason we're running out of IP addresses is because of hording. I know of more than a few original Class B networks which have 10 or less addresses in legitimate use. People are hording addresses because they are worth A LOT of money. One guy I know is trying to sell a Class B to a big CDN and is asking $2 million and it's probably worth it at today's rates.
IPv6 is about features. It's a great protocol and I love it. But let's be honest, I'll be dead long before IPv4 has met its end.
Argh! Can you stop using "theory" in the way you have been. You're hurting my brain. When you say "theory," you really mean "hypothesis." This common confusion is one of the reasons why an utterance like "evolution is only a theory," both sounds like a legitimate rebuttal to lay-people, but also gets the whole thing wrong.
> Again though we see human persuasion at work here: someone persuaded T-Mobile USA that rather than go with IPv4 equipment, they should make the jump to IPv6 and then back port to IPv4.
> T-Mobile USA is known for having a CEO who is focused on shaking up the mobile market and has gone out of his way to identify and promote small gaps in that market as a way of building up customers. In other words, the company is not only open-minded but is actively seeking an edge in the market.
This is a fairly fanciful tale; while I fully acknowledge Mr. Legere's unorthodox business acumen, T-Mobile US's IPv6 initiative predates his time as CEO by at least two years -- I was part of their closed IPv6 beta program (as a customer) at least a year prior.
While he may well have accelerated the initiative upon taking the helm, the decision to start lies with other people inside the business, some of whom are well-known in IPv6 advocacy circles.
It seems unlikely to me that 16% of internet traffic is IPv6, are they just measuring the number of IPv6 endpoints vs total endpoints? Since more and more consumer gear and recent OSes will configure IPv6 there is something there, but AFAIK those changes aren't actually forcing traffic over IPv6.
Personally I disable it in everything I use, because I figure I'll let others find the bugs and enable it when it actually makes a meaningful difference to me as opposed to one more possible source of network issues that I'll have to take into account when something isn't working.
I think the way both Windows and Linux work, if they auto-configure IPv6 and you try to connect to something that has both IPv4 and IPv6 addresses, it will choose the IPv6 by default.
This often gives a clue as to a problem with the IPv6 configuration somewhere, if there's a long delay and then it connects. This is because your end starts by attempting IPv6 and eventually times out when it doesn't actually work because something's eating packets and falls back to the IPv4.
Hi, Number6:
The following could provide a clue. It has been like this for the past few years while that I have been monitoring it. The % of Internet traffic carried by IPv6 appears to be creeping up from 2% to 3%. Of course, it would be lower in the earlier days.
https://ams-ix.net/technical/statistics/sflow-stats/ether-type
Regards,
Abe (2018-09-10 10:37)
just a thought, but maybe they find your mailserver from its publicly published MX records, especially if the spam you receive is addressed to your domain.
It'd be some weird voodoo magic for you to receive spam addressed to a different domain.
Maybe some reading about how email works and comprehension on how you get it is in order?
Thinking it would be a good idea to start enabling IPv6 for our company I asked our provider, Fasthosts, for IPv6 addresses for our dedicated server, back came the reply.....
"I am afraid that Fasthosts does not offer IPv6 addresses for their services and as a result this sadly will not be possible." followed by "Just to follow up on this I received a confirmation that there is no time scale for adding IPv6 support at this time to any Fasthosts products."
So if hosting providers are not going to support IPv6, where is the incentive for users?
The problem I had is my Android phone was very unreliable with IPv6 enabled on my network, it would constantly claim no connection or just take ages to do anything
Also I have all my clients set with static IP addresses but the Xbox One would change its UUID every time its rebooted. That meant I would have connectivity issues every time because I had specific firewall rules to only open incoming connections to specific clients.
Then there is the fact I monitor bandwidth use on my LAN, there doesn't seem to be a facility to do that on IPv6 on pfSense.
So at the end of the day the only choice I had for reliability was to stick with IPv4.
This post has been deleted by its author
Yes, I would agree that IPv6 is giving itself a hard time by not starting with the backward compatibility to IPv4 that is the most fundamental engineering discipline. On the other, it looks that IPv4 has much more fuel in the reserve than the common belief.
A few years ago, we accidentally ventured into the IPv4 address pool exhaustion challenge, perhaps due to the curiosity from our telephony background. We now have submitted to IETF a proposal, named EzIP (phonetic for Easy IPv4):
https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03
EzIP will not only resolve the IPv4 address shortage issues, but also mitigate the root-cause to the cyber security vulnerabilities, plus open up new possibilities for the Internet, all within the confines of the IPv4 domain. These would relieve the urgency to deploy IPv6. However, EzIP has not been granted the permission for publication because its content is not aligned with any of the current IETF Working Groups.
It is interesting to find on this website a later article reporting that IETF engineers are engaged in tense debates with ITU-T:
https://www.theregister.co.uk/2018/05/30/internet_engineers_united_nations_ipv6/
because ITU-T is preparing a Recommendation to require IPv6 be configured in certain way to avoid the digital divide by mapping IPv4 address into IPv6 1:1, among a few other considerations.
https://www.ripe.net/participate/ripe/wg/ipv6/documents/itu-ipv6refmodel
It looks that a lot of actions are forthcoming before the dust can settle down.
I would appreciate feedback and comments.
Abe (2018-07-06 17:00)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
