Anyone Who Still Thinks IPv6 Won't Happen Isn't Watching the Measurements
circleid.com
circleid.com
Comcast: 20.61% -> 24.42%
AT&T: 13.53% -> 16.77%
Verizon Wireless: 40.03% -> 45.75%
Time Warner Cable: 3.88% -> 5.37%
T-Mobile USA: 9.58% -> 15.76%
Google Fiber: 71.87% -> 76.43%
My guess would be that while all Google Fiber customers very well may have IPv6, they may be using some devices that are only IPv4 capable.
Network providers sign up to join the measurement effort and then Google, Facebook, Akamai and Yahoo measure the connections coming from those networks over IPv6 or IPv4. A person at the Internet Society then aggregates the data from the providers and makes it available on the World IPv6 Launch measurements page. The specific mechanisms used to measure IPv6 by the 4 companies are described at the bottom of that measurements web page.
You're better off getting an IPv4 only box and getting a /48 tunnel from HE.net
Why would you possibly want more for a single small VPS? Just because you can?
A /64 is the base unit for public routing. The recommendation is that each single end-site should have a /64. A company or collection of hosts should get a /48. An ISP should have a /32 or perhaps more than one (though I doubt many are big enough to need more than one).
Things are a little confused with VPS providers. If you are running your own box (or boxes) with many VMs for your self/company on it then a /64 for the whole lot is how it is generally done, but for renting out VPSs you should have a /48 and give out /64s to your clients (probably not one per VPS, but one per client).
So essentially, if you are not getting a /64 it is a sign that your provider is doing it wrong. While it may seem a very minor point it could also indicate they have misunderstood or ignored other conventions too.
/96 isn't really bad though - you often see hosts handing out IPv6 addresses like they are IPv4 addresses. Take for example http://serverbros.co.uk/openvz.html, to pick on someone at random via a quick Google search: a whole five v6 addresses! What a generous arrangement!
Actually, that's not quite what RFC6177/RFC3177 say. RFC3177 actually recommended /48's for all end-sites (even home network subscribers) except when it was known by design that only one subnet was needed (a very special case). RFC6177 updated that to be a bit more nuanced, saying that smaller allocations were OK (suggesting /56 for home network subscribers) but still emphasized that end-sites need to have more than just a /64.
> Things are a little confused with VPS providers. If you are running your own box (or boxes) with many VMs for your self/company on it then a /64 for the whole lot is how it is generally done, but for renting out VPSs you should have a /48 and give out /64s to your clients (probably not one per VPS, but one per client).
A VPS provider, being more akin to an ISP, should get a larger allocation (such as a /32; note that Linode actually has a /30 from ARIN). To truly be useful, they should be routing at least a /64 to each VPS, to enable that VPS to perform further routing as needed (for example, if it's running a VPN server).
In IPv6, we need to stop thinking in terms of number of addresses, and start thinking in terms of number of /64 subnets. A /96 may be 4 billion addresses, but it's a fraction of a subnet. There is enough address space in IPv6 to think this way, and in fact the RFCs recommend it.
1. https://github.com/joyent/node/blob/master/src/cares_wrap.cc...
1. https://github.com/joyent/node/blob/master/src/cares_wrap.cc...
At least on Linux and OSX, getaddrinfo() won't return ipv6 addresses if the local machine doesn't have any global ipv6 address, which means that a server without ipv6 connectivity won't waste any cycle trying to use addresses it can't reach.
Preferring v4 means that you'll never shift your traffic over to v6 unless v4 is shut down. Because networks and services are going to be dual stack for as long as sysadmins see substantial v4 traffic, such behavior will create another chicken and the egg problem.
It will also put more strain on the network (as traffic will eventually have to go through multiple layers of NAT, etc), render operations more difficult (how do I know who made that request if an entire datacenter is behind one or two ip addresses?), and in the end, make network operations more expensive, because we'll have to run dual stack longer than necessary.
It really should be as simple as that! Windows Vista supports IPv6, modern versions of OS X supports IPv6, etc. You don't have to configure it - just like you don't have to figure IPv4 with DHCP. Typical end users don't question their IPv4 connectivity, they just plug in their router and things work. The exact same thing should happen with IPv6.
The only issue is going to be old customer routers which can't be upgraded with new firmware.
It would be great if more websites supported IPv6. Like, oh, (cough)(cough)HN(cough)(cough).
For non-HTTPS web there is also: https://www.sixxs.net/tools/gateway/
"Not everything is accessible with NAT64, such as SIP, Skype, MSN, and sites with IPv4 literals.[a] However, 464XLAT RFC 6877,[3] which uses NAT64, allows for such protocols over ipv6 only connections."
One thing that was sad though, is how poorly everything built atop, and around Ruby worked.
This means packets will be dropped but that's not a bad thing when you have other layers taking care of retransmission. So routers then don't have to spend a lot of time chopping packets up and can just either shift packets faster or drop them telling the sender to slow down.
The other advantage I hope we see enabled is multicast. All these streaming services could massively reduce their bandwidth usage if the Internet allowed multicasts.
Anyway, I guess that the oposite of the GPs question. It's IPv6 only clients, not servers, but this is the path that makes more sense.
I still can't see someone running v6 without v4 except as a toy or to prove the point of how bad an experience it would be.
The main problem is that most of the web would be inaccessible. You could mainly visit Google, Facebook, and Wikipedia.
T-mobile is running IPv6 only trial. It works well except for apps that can't handle IPv6 at all and usually because they include addresses in the protocol. Skype is probably the biggest example.
If it's still just a trial, then I can't imagine how they'd get their stats up to 15% so quickly.
Only the old DSL providers like Deutsche Telekom (which is still has the largest market share) can offer real dual stack (with a /56 for IPv6) since they have enough IPv4 addresses and no real growth anymore.
The Airport Base has an IPv6 page that shows what the delegated /64 subnet is. All the devices on my network have autoconfigured themselves with addresses in that range. I appear to be able to manually set hosts to any address in that range as well and it seems to work fine. I do this on some of my server VMs because otherwise they generate a new random address every few days (privacy mode woo). The privacy addressing makes assigning a DNS name to said VM more difficult. I've had the same /64 delegated to me since June 2012.
I've heard that you can request a /60 prefix (16 subnets) if your router supports IPv6 Prefix Delegation (pretty sure the Apple one doesn't). I don't know exactly how you go about doing that though. I'd probably start with the HSI forums on dslreports.com
Edit: If I recall correctly, when Comcast was doing their initial deployment they started with end nodes only (not delegating prefixes). Then moved to delegated /64s. Now are moving on to delegated /60s and more.
http://www.dslreports.com/forum/r27251137-IPv6-Time-Capsule-...
However, it took quite some time for that IPv6 connectivity to finally reach the small city in NH where I live. I'd first contacted TWC about 2.5 years ago asking about IPv6. I stayed in touch with people there over the years getting updates about where the deployment was at. There were issues with various internal equipment/software upgrades, etc. Finally I tried it out in December and found that it all worked and I had native IPv6.
Hopefully you may soon have the same experience.
(I am having some strange problems with Chrome reaching Google sites over IPv6, but I have no idea how to debug them.)
Seems this news article isn't -- http://ready.chair6.net/?url=circleid.com
In particular you may find the "IPv6 for IPv4 Experts" ebook of use: https://sites.google.com/site/yartikhiy/home/ipv6book
https://sites.google.com/site/tmoipv6/lg-mytouch (For T-Mobile, I believe AT&T also has IPv6 available)
Also depends on correct instructions, the linked PDF (under screenshots) there is correct, the instructions at that link do not appear to work.
As for wifi, I can't say, my AP doesn't pass RA's so none of my wireless clients configure to IPv6. Time to add it to the list of stuff to upgrade.
It would be possible to fake it using NAT-PT, or a transparent HTTP proxy with IPv6 on the Internet-facing side, but I doubt that ISPs would be deploying hacks like that on a significant scale.