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.
So am I right in understanding that this is measuring something different from the aforementioned Google statistics? On Google's page it seems to be measuring actual IPv6 traffic, whereas worldipv6launch.org is measuring availability in networks if I'm reading this correctly.
Also, it's not clear what "Google Fiber 76.43%" means. Is that meant to be the percentage of subscribers with IPv6 access? I was under the impression that all Google Fiber customers had IPv6.
It's the percentage of IPv6 adoption seen coming from Google Fiber networks by the companies participating in the World IPv6 Launch measurements program. (See the bottom of http://www.worldipv6launch.org/measurements/ for how IPv6 adoption rates are being measured.)
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.
It's likely 76% that have google fiber, and a router that supports it and their computer setup to work with it. Since it's measured by sites actually reporting the traffic on ipv6 vs ipv4 the ones not on ipv6 are likely those with setups that are preventing proper support.
In IPv6, subnets are designed to be /64. Many things assume this. By giving subscribers shorter prefixes (like /48), you enable them do cool things like run a VPN server where each client has a publicly-routable address (otherwise you have to use NAT like in IPv4). If you give them a longer prefix, like /96, you can't do this sort of thing without a lot of pain. Also, many blacklists assume (for better or worse) that /64s belong to a single customer, so if you're sharing a /64 with other customers, you risk getting blocked for their bad behavior.
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.
He is overreacting a little, but the design of IPv6 was not primarily focused on address depletion, it was more about keeping routing tables simple.
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!
> 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).
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).
I suppose it depends what you consider the "end site" to be (the company/client or the host (virtual or otherwise)). I'm happy to accept other judgement for lack of more certainty myself! Either way I'd expect more than a /96 per client if done right.
IANA guidance (edit: IETF, technically, but no one is disagreeing) is to give every customer at least a /64. Semantically, the first 64 bits are the network address and the last 64 bits are the host address. https://tools.ietf.org/html/rfc5375#appendix-B Practically, they are working very hard to prevent routing table fragmentation. To minimize the size of backbone routing tables, they are granting huge amounts of addresses to anyone who asks, just to make sure that no one needs to use non-contiguous network numbers.
I've got a mac mini co-lo'd with them, haven't tried the VPS myself (but have been tempted to). Out of interest, do you know what virtualisation they use?
Doesn't it iterate over IPv6 addresses a few lines down? [1]. Sure, it iterates through IPv4 first, but does it make sense to prefer IPv6 given that IPv4 is still the most popular?
Yes, it will connect just fine over v6 if no v4 addresses are available. It should, however, try v6 first and then fall back to v4.
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.
All ISPs need to do is provide IPv6 connectivity, a router with IPv6 support - and the traffic will flow.
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.
"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."
Agreed. None of the options for accessing IPv4 only websites via IPv6 only hosts are great. If you are running an IPv4 only website or service this should hopefully worry you.
Our new DC are all IPv6 enabled (we started launching them in December) with dual stack, and preference for IPv6. Only 1 of the DCs are online so far, and we're already pushing around something like 3 Gb/s of traffic over V6. It was nice how many things just magically worked atop V6, once we added AAAA records.
One thing that was sad though, is how poorly everything built atop, and around Ruby worked.
Yes. IPv6 all over. Actually, we're looking at deprecating IPv6 at the transport layer entirely, and moving to IPv4 in IPv6 over GRE tunnels, but that's largely reliant on having RFC5549 in a few specific places (the edge terms).
One of the big wins you get with IPv6 is that is doesn't allow fragmenting.
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.
In Germany the major cable providers are currently switching to DS-Lite which means native IPv6 and carrier-grade NAT for IPv4. The cable companies came a bit late to the broadband party and can't get any more large IPv4 block from RIPE now that they're having a large growth of customers.
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.
You can't even resolve DNS of many/most v6 sites without v4. Specifically, even if someone is serving v6 DNS they often neglect to put a v6 glue record in the root servers (if it's even possible in their TLD).
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.
It is possible to run IPv6 only with NAT64 and DNS64 where the DNS resolver changes IPv4 addresses to IPv6 for proxy that switches protocols.
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.
T-Mobile has moved beyond the trial stage. Lots of Android 4.4 devices ship with an IPv6-only APN, and a 464XLAT daemon that provides connectivity to legacy apps, like Skype.
If it's still just a trial, then I can't imagine how they'd get their stats up to 15% so quickly.
i wouldn't expect anything more than 0% and i don't think there's anything wrong with that. dual stack won't die before ipv6 is much, much more above 50%, probably 90% or so.
At some time the ISPs are going to start connecting their clients only by 6to4 gateways. They are currently using NAT, but NAT is a mess. At some point a proper migration will be cheaper.
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.
Look at browser adaption for a possible time frame. It took time before websites used new cool features like html5, and even longer before they stop supporting older versions like IE4 or WAP/WML.
Is anyone here actually using IPv6 with US cable modem providers (e.g. TWC)? Even though the device connected to the modem gets an IPv6 address, it is completely unclear as to a) what the assigned IPv6 block is or b) how to go about requesting one. It feels like they're in a limbo state of deployment where the edges work but they don't have the workflow/infrastructure set up to dole out address blocks to customers.
I have Comcast cable service in Chicago. I have an SB6120 modem and an Airport Extreme base station. I didn't do anything special beyond plug it in.
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
See, I have exactly the same setup (SB6xxx + AE) and on TWC in NYC it just doesn't work. The AE gets an IPv6 address from the modem, but TWC isn't assigning it a prefix, so all IPv6 devices behind the AE just sit there twiddling their digital thumbs.
TWC is definitely not as far along in their deployment. It might just take some more time. =\
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.
Some older AE/TC don't support DHCP-PD even if you update them with the latest firmware (that's really a shame IMHO).
It might also just be your AE settings. Check that it is configured in router mode, with access mode set to native or automatic.
I'm in Schaumburg, and have had the same experience, but with a Linksys E3200 access point. Plugged into Motorola Comcast modem, and dual-stack came right up.
I am a TWC subscriber and as of December 2013 have IPv6 running perfectly fine in my home network. All my devices get IPv6 addresses and are able to connect to IPv6 test sites fine over IPv6. I'll note that I'm just using a /64 for my home network.
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.
A family friend with Comcast in the Seattle area has an IPv6 address that Google and other sites can see. That is, when they ask Google what their IP address is they only get their IPv6 address back as a response. This can only happen if end-to-end they're routing over IPv6, right?
Does anyone have a recommendation for a good primer on IPv6? Is there something significantly better than reading the IPv6 wikipedia page or googling 'IPv6 primer'?
IPv6 is such a minor win for the Internet now. I'm more excited for a new protocol all together, maybe something like Open Libernet: http://www.openlibernet.org
Many of them already do. My iPhone works wonderfully on my IPv6 home network and connects to sites over IPv6 without a problem. I know this is true for some Android devices as well.
A lot of those numbers are deceptive because carriers are starting to use IPv6 for an outer trunking protocol but the users IPv4 flow is encapsulated within.
I don't think that's right. The stats are based on users' web browsers hitting the measurement points using an IPv6 HTTP connection.
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.
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%