An IPv6 Update [pdf]
conference.apnic.net
conference.apnic.net
I still am.
As IPv4 becomes more scarce, two economic forces trigger
1) They become more valuable (read more desired). IPv4 has all the network effects going for it. It's where 99.9% of the Internet already is. .1% being IPv6 only devices.
2) To counter the rising value/cost: Workaround/Kludges/Alternatives to every devices needing a globally unique address are tried. Everyone is going to reply with how awful NAT is, and I concede it has its flaws. However, it is hard to deny its success so far. Business then do the cost benefit of the shortcomings of things like NAT vs selling their now valuable IPv4 address space, think where they are going to come down?
In particular NAT works both ways, meaning IPv6 only devices have zero issues accessing the IPv4 world via NAT. When used in that way you get the best of both worlds - a world route-able IPv6 address and perfectly backward compatibility.
In the mean time I've rolled our a dual IPv4, IPv6 network that spans the country for my company. Almost zero issues (I had routing bugs). I was blown away to discover that any device that was smart enough to get itself a IPv6 address was smart enough to just work in the mixed environment. And this is in an environment running from XP machines to the latest Android and iPhones.
So we appear to be reached the stage where there are no reasons not to use IPv6. Of course they is also very little reason to move to IPv6 if you have an existing stable IPv4 network. Our networks aren't stable of course, and we are continually adding new connections. We (or rather I) demand a routeable IP address for each of them - life is just too hard otherwise. We are in the APNIC allocation pool that run out of IPv4 addresses ages ago. Right now the ISP's aren't handing out IPv6 addresses. If that ever changes to "you have to pay for an IPv4 address, or you can have a IPv6 address for free", I know which way I will be jumping. It's a no-brainer.
That would be an interesting choice to make, seeing as the surrounding infrastructure is still transitioning and you can just as easily support both stacks. The real obstacles are legacy devices and misconfigured appliances, which can't simply switch over without anyone noticing.
You can see one such analysis at http://www.asgard.org/documents.html
I guess this means carrier-grade NAT works well enough; given this, I can imagine ISPs just don't see enough upside to IPv6 to spend on it.
It would also be interesting to know how much of their traffic winds up on IPv6 tunnels like Teredo anyway to NAT break. Windows by default tries to avoid the worst NATs by using Teredo IPv6 tunneling, and has since Vista.
It's certainly possible that IPv6 traffic already accounts for why users aren't complaining about how much CGNAT breaks IPv4.
Sad but true, but in the ISP's mind, this is exactly "good enough".
Google's IPv6 traffic stats show Teredo traffic is negligible in 2018. https://www.google.com/intl/en/ipv6/statistics.html
My main complaint with that I spent a large amount of time a year ago deploying ipv6 dual stack on my home network. My router is a debian box with shorewall, so I had to learn what was needed all manually. And now, a year later, I'm not even sure how it works as I've forgotten everything. It took a bit of work to figure out how to get my router/shorewall box to request an ipv6 prefix for each internal interface, and then how all that is handled. And now I don't even know lol
So if this local ISP doesn't offer IPV6, I get to tear all that down and then I guess start over again re-learning in a future date.
I think you can just set one of those up and keep using IPv6 regardless of whether or not your ISP gives you an IPv6 prefix; when they do, just switch over to that.
During the later part of last year I think they managed to get over 100M customers...
[0] https://www.vyncke.org/ipv6status/project.php?metric=p&timef... (data from [1])
We came upon a scheme that can expand each public IPv4 address by 256M (Million) fold without affecting the current Internet. A proposal called EzIP (phonetic for Easy IPv4) has been submitted to IETF:
https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-add...
Essentially, among other benefits, EzIP can establish a sub-Internet capable of serving an area with up to 256M IoTs, from just one IPv4 address. This is bigger than the largest city (Tokyo metro) and 75% of the countries. This can realize the CIR (Country-based Internet Registry) model proposed by ITU a few years ago stealthily even without setting up a CIR organization. If a government is not interested in this resources, private enterprises can make use of it to provide "local" Internet service in parallel to the current "global" Internet model, very much like the Independent telephone companies in the PSTN industry.
The current Internet then becomes the backbone / infrastructure / skeleton for interconnecting these sub-Internets, yet only for carrying inter sub-Internet traffic, very similar as the electric grid supporting islands of renewable energy generated by individual homes and businesses. Consequently, there will be a lot of spare IPv4 addresses for quite sometime to come.
In terms of the IP address length, the basic EzIP header format proposes to double it by utilizing the Option Word mechanism in the IP Header to make the overall system 64 bits. It is just as well to make the Option Word to carry longer bits like up to 96 bits so that the overall address system becomes 128 bit, in the same class as IPv6 while totally staying IPv4 within conformance.
Then, much of the efforts in developing and deploying IPv6 are no longer needed.
Thoughts and comments will be much appreciated.
Abe (2018-09-15 12:48)
So when I started hosting a side-project I made sure it was accessible via IPv6. Skimming through logs many people connect through IPv6 as well, so I'm a bit surprised when I read that deployment is slowing down.
Most measurements are over https. If they intrude a fake TLS certificate in the flow (for instance) which is common in strategic DPI inside secure channels the web blot won't fetch properly.
We've started looking at tshark captures to see if we can see partial connects.