IPv6 Adoption Statistics(google.com)
google.com
IPv6 Adoption Statistics
http://www.google.com/intl/en/ipv6/statistics.html
133 comments
Privacy Extensions is dangerous: http://blog.bimajority.org/2014/09/05/the-network-nightmare-...
I haven't read the long article but it ends with:
> UPDATE (2014-09-06): As […] was the first to point out, RFC 7217 addresses all of my issues with “privacy” addresses. Let implementation come soon!
So, not backing your message.
> UPDATE (2014-09-06): As […] was the first to point out, RFC 7217 addresses all of my issues with “privacy” addresses. Let implementation come soon!
So, not backing your message.
This seems like the case of a very specific problem for a large network. I don't believe that in a typical home or small office setting this would have a bad effect.
I recently had to disable ipv6 because my router started freaking out about "neighbor table overflow". Some kind of issue between Asus and Comcast.
This error is caused by a bug[1] present on outdated versions of Linux (typically exhibited by DD-WRT and Tomato routers) and can also be fixed by upgrading to OpenWRT.
Or, if that is not an option, by creating an ip6tables rule:
Or, if that is not an option, by creating an ip6tables rule:
ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor-solicitation -i `nvram get wan0_ifname` -d ff02::1:ff00:0/104 -j DROP
sysctl net.ipv6.neigh.default.gc_thresh1=256
sysctl net.ipv6.neigh.default.gc_thresh2=512
sysctl net.ipv6.neigh.default.gc_thresh3=1024
I will try that, thanks!
After I switched ISP to one that supports native IPv6 (and generally is pure awesome), I noticed that my traffic at home went to about 50% IPv6, also thanks to YouTube supporting V6.
I also casually noticed that all but one address in my "Account Activity" view in Gmail are IPv6 addresses (ironically, the mobile phone got the one single IPv4 address in that list over 4G).
V6 works nicely and totally transparent causing zero trouble for me, even though there are some application protocols that don't handle V6 properly yet (Apple Remote Desktop and Air Video to give two examples).
One thing that's tricky about V6 is the fact that without NAT all your boxes are internet-reachable unless you have a firewall. That's easily added of course, but whereas we have protocols like upnp and nat-pmp to reconfigure NAT routers, there's nothing equivalent for various applications to tell the router to forward some V6 traffic.
So this is actually a step back what connectivity behind LANs is concerned.
I would love for applications to be able to ask the OS for their very own application specific v6 address. Then they could just listen on that instead of all interfaces (and listening on all interfaces would not include these application specific interfaces).
That way, I could theoretically get away without a restrictive firewall while still giving applications a way to be directly connected to. An attacker would have to scan a /48 (in my case) or a /64 (in the worst case) in order to find an open port given a known remote address.
I also casually noticed that all but one address in my "Account Activity" view in Gmail are IPv6 addresses (ironically, the mobile phone got the one single IPv4 address in that list over 4G).
V6 works nicely and totally transparent causing zero trouble for me, even though there are some application protocols that don't handle V6 properly yet (Apple Remote Desktop and Air Video to give two examples).
One thing that's tricky about V6 is the fact that without NAT all your boxes are internet-reachable unless you have a firewall. That's easily added of course, but whereas we have protocols like upnp and nat-pmp to reconfigure NAT routers, there's nothing equivalent for various applications to tell the router to forward some V6 traffic.
So this is actually a step back what connectivity behind LANs is concerned.
I would love for applications to be able to ask the OS for their very own application specific v6 address. Then they could just listen on that instead of all interfaces (and listening on all interfaces would not include these application specific interfaces).
That way, I could theoretically get away without a restrictive firewall while still giving applications a way to be directly connected to. An attacker would have to scan a /48 (in my case) or a /64 (in the worst case) in order to find an open port given a known remote address.
While having an unique address per application can be cool, I don't like the premise that this is used as some sort of security layer.
We have firewalls. We know how they work and how to implement them well. For all intents and purposes a typical NAT-setup is bascially wide open from the inside and out. You can do the same with a few simple rules on a firewall.
We have firewalls. We know how they work and how to implement them well. For all intents and purposes a typical NAT-setup is bascially wide open from the inside and out. You can do the same with a few simple rules on a firewall.
I know we have firewalls, but in the normal desktop use-case, there are some applications that you want to be able for external clients to connect to.
Skype (or other VoIP clients), Bittorrent, Game servers, etc all work better with or flat-out require external connectivity.
In the V4 world, we have upnp or NAP-PMP to allow applications to open a port on the router and to have the router then forward the packets to a client behind the router.
In the V6 world there's no equivalent protocol even though the work needed would be smaller (forwarding to a given host/port combination is enough - no port mapping).
It's bizarre that at the moment, servers on my various machines at home get better connectivity over IPv4 (thanks to NAP-PMP) than over IPv6 (thanks to my firewall).
Having application specific addresses would provide more than enough security for many simpler LANs (good luck guessing a 64 or even 80 bit number in order to get the one where the "juicy" ports are open) to use in absence of a v6 compatible NAP-PMP equivalent.
I would totally trust the 80 bits of pool size as a sufficient security boundary and I'd disable the IPv6 firewall for my home network if this concept of application specific addresses would exist.
This would also be much closer to the ideal of the old times where every machine was assumed to be connectible without additional configuration anywhere.
Skype (or other VoIP clients), Bittorrent, Game servers, etc all work better with or flat-out require external connectivity.
In the V4 world, we have upnp or NAP-PMP to allow applications to open a port on the router and to have the router then forward the packets to a client behind the router.
In the V6 world there's no equivalent protocol even though the work needed would be smaller (forwarding to a given host/port combination is enough - no port mapping).
It's bizarre that at the moment, servers on my various machines at home get better connectivity over IPv4 (thanks to NAP-PMP) than over IPv6 (thanks to my firewall).
Having application specific addresses would provide more than enough security for many simpler LANs (good luck guessing a 64 or even 80 bit number in order to get the one where the "juicy" ports are open) to use in absence of a v6 compatible NAP-PMP equivalent.
I would totally trust the 80 bits of pool size as a sufficient security boundary and I'd disable the IPv6 firewall for my home network if this concept of application specific addresses would exist.
This would also be much closer to the ideal of the old times where every machine was assumed to be connectible without additional configuration anywhere.
Isn't it easy enough to just have a local firewall on each machine where you open up ports for the apps you want to be public?
The firewall on a local machine might suffer from exploits, thus still allowing access.
Or I might want some services open to my lan and only a smaller subset opened to the public (something the personal firewalls built into many OSes can't do)
Or I might want some services open to my lan and only a smaller subset opened to the public (something the personal firewalls built into many OSes can't do)
> The firewall on a local machine might suffer from exploits, thus still allowing access.
Is a updated firewall from Apple, Microsoft or ipfw more or less likely to suffer from exploits than a cut-rate device from ASUS, Netgear or Linksys that hasn't been updated in years?
> Or I might want some services open to my lan and only a smaller subset opened to the public (something the personal firewalls built into many OSes can't do)
That may be fair enough but that's just a reason to improve the firewalls in the OSes. As soon as you tether to your phone or use public WiFi you're going to want a solid local firewall anyhow.
Is a updated firewall from Apple, Microsoft or ipfw more or less likely to suffer from exploits than a cut-rate device from ASUS, Netgear or Linksys that hasn't been updated in years?
> Or I might want some services open to my lan and only a smaller subset opened to the public (something the personal firewalls built into many OSes can't do)
That may be fair enough but that's just a reason to improve the firewalls in the OSes. As soon as you tether to your phone or use public WiFi you're going to want a solid local firewall anyhow.
The idea is that it can be turned off from the machine itself, so eg if you get hacked via a website or email, your firewall might get disabled, while another box would also need to be hacked. (Of course things like UPNP give the machines control over the router so making this moot, which is why I dodnt run them).
> Of course things like UPNP give the machines control over the router so making this moot
Yep this was exactly my point
Yep this was exactly my point
I don't really think they get better connectivity. If you can establish a connection from the inside things works as intended for basically everything. Peer-to-peer is a little different.
Personally I find it a little scary that we allow applications to just open up inbound ports as they see fit. Would you, say, install MySQL locally and have it listen on such an address because it's so unlikely that anyone will ever find it anyway?
Personally I find it a little scary that we allow applications to just open up inbound ports as they see fit. Would you, say, install MySQL locally and have it listen on such an address because it's so unlikely that anyone will ever find it anyway?
If you install MySQL locally, you should not have it listen on any address other than the loopback by default.
And when you do expose it, if you care about security, you should configure the appropriate iptables along the way there and then, rather than relying on a magic box somewhere upstream filtering the packets.
This can be doubly useful if the box in question your laptop which you carry around in various, potentially hostile, environments.
And when you do expose it, if you care about security, you should configure the appropriate iptables along the way there and then, rather than relying on a magic box somewhere upstream filtering the packets.
This can be doubly useful if the box in question your laptop which you carry around in various, potentially hostile, environments.
I was just using MySQL as a hypothetical example, as they listen on all interfaces by default with packages supplied by Oracle. Next time you're on a tech conference, do a scan on the local network.
My point was that by his standard he would just let it listen on all interfaces because in his own word, nobody would find it. Which sounds very naive.
My point was that by his standard he would just let it listen on all interfaces because in his own word, nobody would find it. Which sounds very naive.
Okay then I think we were in violent agreement.
I was arguing the whole "listen on all interfaces by default" is wrong - if one needs to expose the app, they should do so explicitly, and you did the same.
I was arguing the whole "listen on all interfaces by default" is wrong - if one needs to expose the app, they should do so explicitly, and you did the same.
[deleted]
> We have firewalls. We know how they work and how to implement them well. For all intents and purposes a typical NAT-setup is bascially wide open from the inside and out.
Now consider source routing.
Yup.
Now consider source routing.
Yup.
> One thing that's tricky about V6 is the fact that without NAT all your boxes are internet-reachable unless you have a firewall. That's easily added of course, but whereas we have protocols like upnp and nat-pmp to reconfigure NAT routers, there's nothing equivalent for various applications to tell the router to forward some V6 traffic.
Is there any reason the same approach shouldn't work? All the application needs to tell the router is "please open this inbound port on this address", right? Like, in theory couldn't a router just follow the existing uPNP/nat-pmp standards and do the right thing with those messages?
> That way, I could theoretically get away without a restrictive firewall while still giving applications a way to be directly connected to. An attacker would have to scan a /48 (in my case) or a /64 (in the worst case) in order to find an open port given a known remote address.
I think that's a terrible idea. An attacker could e.g. sniff packets inbound towards your network to figure out the address. Addresses are not designed to be secret or a security feature.
Is there any reason the same approach shouldn't work? All the application needs to tell the router is "please open this inbound port on this address", right? Like, in theory couldn't a router just follow the existing uPNP/nat-pmp standards and do the right thing with those messages?
> That way, I could theoretically get away without a restrictive firewall while still giving applications a way to be directly connected to. An attacker would have to scan a /48 (in my case) or a /64 (in the worst case) in order to find an open port given a known remote address.
I think that's a terrible idea. An attacker could e.g. sniff packets inbound towards your network to figure out the address. Addresses are not designed to be secret or a security feature.
All you need is a firewall. NAT is not a security feature: it just has security implications. In IPv4 land, it's the firewall that does all the port forwarding, etc. anyways.
If you are running IPv6, get a nice OpenWRT router, where the firewall is enabled by default.
If you are running IPv6, get a nice OpenWRT router, where the firewall is enabled by default.
What are the implications of using a laptop on a public Wifi where you don't control the router? (Or a friend's house, or anywhere else where the router isn't yours).
OS-level firewall, I guess? Which maybe you should probably have anyway?
OS-level firewall, I guess? Which maybe you should probably have anyway?
I think a lot of people don't trust the OS firewall due to many years of using Windows firewall. Windows firewall hasn't always been good, and is confusing still to this day for a lot of users (when I search for Firewall in my Windows 7 start menu, I get no less than 4 different options which all present me with different context menus, etc). Not to mention security product vendors still try to peddle their 3rd party firewall as being superior to the built-in firewall, which is rubbish other than maybe a usability standpoint (you either block something or you don't).
Compounded by the fact that most Windows boxes are "leaky" over the network and often have services talking without the user's knowledge.
This is changing, but it will take time to change user's minds. In the *nix world (which includes OSX), the desktop firewalls in my experience have been good for a very long time.
Compounded by the fact that most Windows boxes are "leaky" over the network and often have services talking without the user's knowledge.
This is changing, but it will take time to change user's minds. In the *nix world (which includes OSX), the desktop firewalls in my experience have been good for a very long time.
Windows gives you the choice when you connect to the Wifi - a kind of "is this network trusted?" dialogue.
Honestly the thing that makes sense is smarter applications. If you only need local connectivity, only listen on the loopback interface. If you open a port then you should expect to receive public requests on this port, and should have appropriate authentication in place.
Honestly the thing that makes sense is smarter applications. If you only need local connectivity, only listen on the loopback interface. If you open a port then you should expect to receive public requests on this port, and should have appropriate authentication in place.
The protocol you're looking for is PCP which is the NAT-PMP successor that also works with IPv6: https://en.wikipedia.org/wiki/Port_Control_Protocol
Unfortunately it's going to take a while until it's widely supported.
Unfortunately it's going to take a while until it's widely supported.
"One thing that's tricky about V6 is the fact that without NAT all your boxes are internet-reachable unless you have a firewall."
Maybe OSes will need to stop assuming their underbellies can be soft and implement some real host security.
Naaahhh... hell will freeze over first.
Maybe OSes will need to stop assuming their underbellies can be soft and implement some real host security.
Naaahhh... hell will freeze over first.
I'd be very interested in knowing how these stats were calculated - 12% of the United States on IPv6 seems a bit high. Maybe what Google is saying is that "It's Available, but we're not saying people are using it." - For example, Comcast has had IPv6 widely deployed for at least a year, so most of their customer might be identified as "Available" - even if their browsers aren't doing a AAAA lookup for www.google.com.
Not in the least. For all their atrocities, Comcast was one of the early IPv6 adopters and has rolled it out to their entire residential customer base (people with older modems/routers that don't support IPv6 obviously won't pull an IPv6 IP address). That's EASILY 11% of US internet traffic.
Just curious, do the internal interfaces on Comcast's IPv6 routers give out V4 or V6 addresses?
I think that's the point I was trying to make.
The page says "The graph shows the percentage of users that access Google over IPv6.", so I would assume this would mean people are actually using it.
This reflects the shift of traffic to mobile.
Everyone using Verizon Wireless with an IPv6 capable device is using IPv6. It's behind some sort of carrier grade proxy, but is IPv6.
Everyone using Verizon Wireless with an IPv6 capable device is using IPv6. It's behind some sort of carrier grade proxy, but is IPv6.
Also, if you are using T-mobile, you can use IPv6-only, and they have a few million subscribers.
I got a T-mobile SIM when I was in the US last month, and switched to IPv6-only APN. Worked pretty well for the casual browsing - and the non-IPv6 websites were still reachable using NAT64 on T-mobile's side. Though the possibility to do IPv6-only might depend on your handset.
I got a T-mobile SIM when I was in the US last month, and switched to IPv6-only APN. Worked pretty well for the casual browsing - and the non-IPv6 websites were still reachable using NAT64 on T-mobile's side. Though the possibility to do IPv6-only might depend on your handset.
Indeed. You can test it on Verizon by doing a Google search for: ip
It should give you your mobile's IPv6 address.
It should give you your mobile's IPv6 address.
> I'd be very interested in knowing how these stats were calculated
Reasonably sure it's based off something similar to this: https://www.ietf.org/proceedings/73/slides/v6ops-4.pdf
And yes, it is basically 12% of US users are capable of connecting to google over ipv6, not that they necessarily did/have. A browser might, for a URL that resolves to both v4 and v6 addresses, always try the v4 address first; this'd give you users that _can_ connect over v6 but don't. FWIW I have a v6-capable connection and find on chrome I pretty much always connect to google and facebook over ipv6, but I have no idea how IE/FF/Safari behave.
Reasonably sure it's based off something similar to this: https://www.ietf.org/proceedings/73/slides/v6ops-4.pdf
And yes, it is basically 12% of US users are capable of connecting to google over ipv6, not that they necessarily did/have. A browser might, for a URL that resolves to both v4 and v6 addresses, always try the v4 address first; this'd give you users that _can_ connect over v6 but don't. FWIW I have a v6-capable connection and find on chrome I pretty much always connect to google and facebook over ipv6, but I have no idea how IE/FF/Safari behave.
The presentation is from... long time ago :-)
Now they serve to everyone over IPv4 and IPv6 and these stats are the actual IPv4 requests vs. IPv6 requests that they get, not some projected number.
On address selection:
Safari uses Apple API which has a proprietary mechanism for determining whether IPv4 or IPv6 gives a better user experience. You can approximate this as an RTT race between IPv4 and IPv6 connection (thus, somewhat of a flavour of what we describe in RFC6555).
Firefox/Chrome give a small headstart (~150-300ms) to IPv6.
IE strongly prefers IPv6, except if a particular MS-hosted IPv6 site is not reachable, then it strongly prefers IPv4.
Now they serve to everyone over IPv4 and IPv6 and these stats are the actual IPv4 requests vs. IPv6 requests that they get, not some projected number.
On address selection:
Safari uses Apple API which has a proprietary mechanism for determining whether IPv4 or IPv6 gives a better user experience. You can approximate this as an RTT race between IPv4 and IPv6 connection (thus, somewhat of a flavour of what we describe in RFC6555).
Firefox/Chrome give a small headstart (~150-300ms) to IPv6.
IE strongly prefers IPv6, except if a particular MS-hosted IPv6 site is not reachable, then it strongly prefers IPv4.
They should all use the "Happy Eyeballs" algorithm (https://tools.ietf.org/html/rfc6555)
I think mobile ISPs are leading the charge here. I know my phone on T-Mobile is using IPv6.
Everyone who uses IPv6 also uses IPv4, but IPv6 is used whenever site supports it, and when they have to fallback they most likely connect through CGNAT).
For example everyone on Verizon who uses 4G uses IPv6 by default and CGNAT for sites that are IPv4.
When IPv6 is implemented correctly, the user doesn't even know when he/she is using IPv6.
For example everyone on Verizon who uses 4G uses IPv6 by default and CGNAT for sites that are IPv4.
When IPv6 is implemented correctly, the user doesn't even know when he/she is using IPv6.
In Austria not having IPV6 support is a feature, and I assume it's that way in many countries. If an ISP rolls out IPv6 for you here you lose your public IPv4 address (DS-Lite).
Here in Russia many (most?) consumer providers have IPv4-only carrier grade NATs and sell public addresses with additional monthly fees. This happened gradually: when providers run out of addresses they had not fast enough routers for DS Lite, but after transition to NATs they got incentive to keep additional revenues from people who pay for public addresses.
So if in your country some ISPs are too slow to roll out IPv6, may be they have plans worse.
So if in your country some ISPs are too slow to roll out IPv6, may be they have plans worse.
Widespread carrier grade NAT is inevitable, because we simply have more people than IPv4 addresses.
Just because an ISP is rolling out CGN and IPv6 together doesn't imply that IPv6 is an anti-feature. It's certainly better to have CGNv4+IPv6 than CGNv4 alone.
Just because an ISP is rolling out CGN and IPv6 together doesn't imply that IPv6 is an anti-feature. It's certainly better to have CGNv4+IPv6 than CGNv4 alone.
you mean you currently have a static IPv4 IP?
No. You have an IPv4. Does not matter if dynamic or static. With DS-Lite you have neither. You're behind a carrier level NAT.
I would agree that carrier grade NAT is a downgrade
It's horrible. I don't even see the point. IPv4 and an IPv6 can cohabit. Why would they even alter your IPv4 access?
Presumably because they have run out of IPV4 addresses
Australia is under APNIC, which started rationing out its last /8 IP block in 2011.
Australia has a decent number of allocated addresses, around 2 per capita (compare with India, with 29 addresses per 1000 persons)[1], but presumably they will have to be reclaimed from existing users.
A newly started ISP in Australia could get a maximum of 2048 IPv4 addresses from APNIC. [2] If it needed more it would have to transfer them from another owner.
[1] http://en.wikipedia.org/wiki/List_of_countries_by_IPv4_addre...
[2] http://www.apnic.net/community/ipv4-exhaustion/ipv4-exhausti...
Australia has a decent number of allocated addresses, around 2 per capita (compare with India, with 29 addresses per 1000 persons)[1], but presumably they will have to be reclaimed from existing users.
A newly started ISP in Australia could get a maximum of 2048 IPv4 addresses from APNIC. [2] If it needed more it would have to transfer them from another owner.
[1] http://en.wikipedia.org/wiki/List_of_countries_by_IPv4_addre...
[2] http://www.apnic.net/community/ipv4-exhaustion/ipv4-exhausti...
Out of curiosity (I live in the UK, a country that does not believe in adopting new technologies less than 5y after everyone else), with IPv6, there is no need for a NAT anymore. Will the local networks be directly on the WAN? Will be interesting from a security/privacy point of view. Unless routers act as firewall, in which case we are back to square 1...
Most home routers already act as an inbound firewall. Regarding "back to square 1" - the aim of IPv6 is not to expose thousands of poorly secured LAN devices to the public net - it's to restore the point-to-point nature of the internet. I would still expect most LANs to be firewalled when IPv6 is adopted
Just to expand on that, with IP6, it would make sense to simply give every router, DSL "modem" etc a [ed: theoretically, publicly] routable ipv6 subnet. This makes (in theory) everything easier: the firewall can simply block/allow -- no need for long chains of NAT-rules. It might make networks marginally more transparent -- but it really means very little in terms of security. Nor really for privacy.
Addressable != routable.
Think of a doorman for a luxury building or a gated community. The people living inside have publicly available addresses, but knowing the addreses doesn't mean that the doorman will automatically let you through to go visit.
Think of a doorman for a luxury building or a gated community. The people living inside have publicly available addresses, but knowing the addreses doesn't mean that the doorman will automatically let you through to go visit.
You will still need a router at home, and it can still filter any packets coming in/going out, even if the connected devices have globally accesible addresses. So, there should not be a huge problem.
Can somebody explain how Belgium achieved 28%? It's the only country that's colored bright green.
Telenet (one of the biggest ISPs in Belgium) deployed IPv6 for their whole customerbase.
They plan to have all up-to-date modems provisioned with IPv6 before the end of this year.
They plan to have all up-to-date modems provisioned with IPv6 before the end of this year.
We have only 2 ISPs that completely dominate the market. Both have rolled out IPv6. Technically everyone can be on IPv6 but there are stil a lot of old routers in circulation.
Interesting. Belgium shows up so small in the map in that page that I didn't even notice it was bright green, and therefore didn't include it in the title.
[deleted]
Because we pay too much for our internet :P
EDPnet, a smaller ISP has been natively providing IPv6 for ~3 years already (but 3rd biggest independent ISP?).
Telenet followed somewhere last year, and Belgacom (biggest) followed this year (only on new modems though).
Telenet followed somewhere last year, and Belgacom (biggest) followed this year (only on new modems though).
Voo is doing IPv6 as well, AFAIK.
http://www.worldipv6launch.org/measurements/ gives a per-AS breakout, with the %%% being the massaged number as seen by the content-provider participants.
http://www.worldipv6launch.org/measurements/ gives a per-AS breakout, with the %%% being the massaged number as seen by the content-provider participants.
I've looked around and I can't find one ISP that "support" ipv6 in Sweden. The big ones alway replies with "We have enough ipv4 addresses for a long time forward, you don't have to worry."
I'm not worried, I just want to have ipv6 access.
I'm not worried, I just want to have ipv6 access.
IPv6 became available to me on my Comcast connection in the past six months, but I ended up disabling it at my local router. Unfortunately it seems in my area (North of Boston, MA) the IPv6 routing on Comcast's network is extremely spotty. Sometimes connections would time out on all different ports (22, 80, 443). This lead to a rather poor experience for members of my household. I ran into lots of issues with SSH. My wife ran into lots of issues using apps on her iPhone. She was switching to her mobile data connection on a regular basis to work around the issue. Since disabling IPv6 on our network, all of the issues have gone away.
Did you contact Comcast about this issue? I know some of the folks involved with the IPv6 rollout there and they are VERY focused on making the IPv6 experience as painless as possible.
No, after spending 3 weeks and 6 hours on the phone to add the correct TV to my account I gave up spending time with Comcast.
If you happen to know a competent contact that I can provide info to, I'd be happy. But I am not going to waste my time trying to get through to them via normal channels.
If you happen to know a competent contact that I can provide info to, I'd be happy. But I am not going to waste my time trying to get through to them via normal channels.
@wbond I run the program at Comcast, want to ping me offline?
I found that switching to googles DNS fixed those issues for me (I'm on the south shore).
There is still the occasional delay, but its similar to the ipv4 service from Comcast.
There is still the occasional delay, but its similar to the ipv4 service from Comcast.
I had to switch dns for ipv4 regardless.
But ipv6 actually seems to be around 50% of my traffic now. Native dual stack is way better than the tunnel nonsense they were trialing a few years back. I've had zero issues with ipv6 and comcast now that they went to proper dual stack.
But ipv6 actually seems to be around 50% of my traffic now. Native dual stack is way better than the tunnel nonsense they were trialing a few years back. I've had zero issues with ipv6 and comcast now that they went to proper dual stack.
I've been trying on and off to get IPv6 working at home, but the problem I keep running into is poor performance from tunnels. I have service via Wide Open West which is great for IPv4, but they have no plans to support IPv6. So, I try using a tunnel...
Both HE.net and SixXS are so incredibly slow that I get >1 second pings to something which is 30ms away via IPv4. The tunnel end point is only ~50ms away, so I can only see the latency as being within the tunnel provider...
I really, really wish that I had a native IPv6 connection at home, but I don't want to switch to Comcast, which is the only IPv6 option for me.
Both HE.net and SixXS are so incredibly slow that I get >1 second pings to something which is 30ms away via IPv4. The tunnel end point is only ~50ms away, so I can only see the latency as being within the tunnel provider...
I really, really wish that I had a native IPv6 connection at home, but I don't want to switch to Comcast, which is the only IPv6 option for me.
Shoot an email to HE. Their support for this free service is better than most commercial support teams I've interacted with.
Also, don't discount that it's possible that the other end of the equation, the server you are trying to reach, has poor IPv6 connectivity. Fire up a Digital Ocean instance for an hour (it'll cost you $0.10) and see if the site is slow from everywhere.
I've been using HE.net's tunnels for a good long while now and they've been great for me.
Also, don't discount that it's possible that the other end of the equation, the server you are trying to reach, has poor IPv6 connectivity. Fire up a Digital Ocean instance for an hour (it'll cost you $0.10) and see if the site is slow from everywhere.
I've been using HE.net's tunnels for a good long while now and they've been great for me.
Unfortunately, it's anything that's slow... When I've got a tunnel live, Google properties and Facebook are pretty much unusable. Weirdly, sometimes it'll work fine... Other times it won't. (The server I'm testing against with is my personal site, https://nuxx.net, which has great IPv6 connectivity already. I just don't want to tunnel my home connection through it because that'll seriously push up the bandwidth use of the hosted server.)
There's two things that I haven't taken the time to rule out yet: my router potentially being problematic (it's an Apple Airport that otherwise works well) and the ISP slowing down tunneled traffic. The former would require setting up a new router, and the latter... I'm not sure how I'd do that yet. IPv6 connectivity had been working fine until a month or two ago when things just went weird.
Good thought on sending HE a message... I'll do that later today. Maybe there's something they've run into before with this combo. When their tunnel was up and working great it was surprisingly nice.
There's two things that I haven't taken the time to rule out yet: my router potentially being problematic (it's an Apple Airport that otherwise works well) and the ISP slowing down tunneled traffic. The former would require setting up a new router, and the latter... I'm not sure how I'd do that yet. IPv6 connectivity had been working fine until a month or two ago when things just went weird.
Good thought on sending HE a message... I'll do that later today. Maybe there's something they've run into before with this combo. When their tunnel was up and working great it was surprisingly nice.
This description might also match a partly-working path MTU discovery (a possibly too-high rate of ICMP egress from HE end to content sites, blocked by rate-limiter on the HE device).
In IPv4 you do not notice it (it almost never triggers) because there is less tunnels and also because generally everyone does MSS clamping. In IPv6, you have the tunnel and not necessarily MSS clamping.
Two ways to tackle it:
- configure on the home router interface facing your LAN, IPv6 MTU less than you have on the tunnel (I have 1400 just because I like round numbers :-) Cleaner because works for (mostly) all protocols.
- configure the first hop router to do MSS clamping for TCP on IPv6 to 20 bytes less than what it currently does (if at all). This will work for only TCP, but that'll be the vast percentage of the traffic you are having problems with.
In IPv4 you do not notice it (it almost never triggers) because there is less tunnels and also because generally everyone does MSS clamping. In IPv6, you have the tunnel and not necessarily MSS clamping.
Two ways to tackle it:
- configure on the home router interface facing your LAN, IPv6 MTU less than you have on the tunnel (I have 1400 just because I like round numbers :-) Cleaner because works for (mostly) all protocols.
- configure the first hop router to do MSS clamping for TCP on IPv6 to 20 bytes less than what it currently does (if at all). This will work for only TCP, but that'll be the vast percentage of the traffic you are having problems with.
So... Changing the MTU didn't help. Even at the minimum of 1200 I still had issues. Sometimes pings (even small 60 byte ones) would be fast, other times they'd be upwards of one second. Not sure what's going on yet, as I've put working on this aside for now.
Okay, if there is a jitter on individual pings, it is certainly not the PMTUD-related - and if there is no packet loss, then it is shaping - either intentional, or some middlebox can't cope with the load.
When using AICCU (sixxs) - were you using protocol 41 or the UDP-based encap ? if protocol 41, then experimenting with switching to UDP might be interesting.
When using AICCU (sixxs) - were you using protocol 41 or the UDP-based encap ? if protocol 41, then experimenting with switching to UDP might be interesting.
This is a very good thought, and something I hadn't tried yet... Mostly due to the sporadic functionality of the issue. I'll give this a go tonight; thank you.
You could try glasnost:
http://broadband.mpi-sws.org/transparency/glasnost.php
It probably won't help you with your specific tunnel, but you can check other traffic to see if there's any filtering occurring. It seems unlikely they'd ONLY throttle ipv6 tunnel traffic.
Also, the other thing I ran into with he.net tunnel was a problem with pmtu discovery. I had to manually set the mtu/mss on my router (pfsense). I have no idea if the airport will even let you.
https://forums.he.net/index.php?topic=3028.0
It probably won't help you with your specific tunnel, but you can check other traffic to see if there's any filtering occurring. It seems unlikely they'd ONLY throttle ipv6 tunnel traffic.
Also, the other thing I ran into with he.net tunnel was a problem with pmtu discovery. I had to manually set the mtu/mss on my router (pfsense). I have no idea if the airport will even let you.
https://forums.he.net/index.php?topic=3028.0
> I've been using HE.net's tunnels for a good long while now and they've been great for me.
Same here. As of about a year or two ago, my pings over the HE tunnel are only very slightly worse than those over my IPv4 interface, and I can't notice much difference in throughput. I've encountered minor issues with their tunnel servers from time to time, but usually by the time I notice the problem is resolved.
I also have to second that their support is absolutely fantastic. Plus there's always their forums, in case someone else has run into something similar. Many of tunnelbroker.net's users are equally friendly and helpful.
Same here. As of about a year or two ago, my pings over the HE tunnel are only very slightly worse than those over my IPv4 interface, and I can't notice much difference in throughput. I've encountered minor issues with their tunnel servers from time to time, but usually by the time I notice the problem is resolved.
I also have to second that their support is absolutely fantastic. Plus there's always their forums, in case someone else has run into something similar. Many of tunnelbroker.net's users are equally friendly and helpful.
They do rate limit you to around 4Mb I believe so you might want to not ship your netflix over them, which it will unless you are careful.
Reference? I couldn't find anything about it, and have been watching Netflix through them for at least three years now.
Thats what a friend claimed, although HE seem to deny it. I had to disable it for Netflix as it got geolocation wrong, so probably never really tested it.
Weird. I use HE.net as well and often the latency on V6 is better than it is on V4:
My results at the moment:
ping6 google.com PING6(56=40+8+8 bytes) [Redacted] --> 2607:f8b0:4009:807::1000
16 bytes from 2607:f8b0:4009:807::1000, icmp_seq=0 hlim=58 time=22.727 ms
16 bytes from 2607:f8b0:4009:807::1000, icmp_seq=1 hlim=58 time=21.862 ms
16 bytes from 2607:f8b0:4009:807::1000, icmp_seq=2 hlim=58 time=25.147 ms
vs.
ping google.com
PING google.com (216.58.216.224): 56 data bytes
64 bytes from 216.58.216.224: icmp_seq=0 ttl=251 time=37.229 ms
64 bytes from 216.58.216.224: icmp_seq=1 ttl=251 time=36.672 ms
64 bytes from 216.58.216.224: icmp_seq=2 ttl=251 time=38.319 ms
I think this is due to my provider (Verizon) being a dick with their peering agreements and the HE.net traffic goes over a less congested pipe than my ordinary v4 traffic.
My results at the moment:
ping6 google.com PING6(56=40+8+8 bytes) [Redacted] --> 2607:f8b0:4009:807::1000
16 bytes from 2607:f8b0:4009:807::1000, icmp_seq=0 hlim=58 time=22.727 ms
16 bytes from 2607:f8b0:4009:807::1000, icmp_seq=1 hlim=58 time=21.862 ms
16 bytes from 2607:f8b0:4009:807::1000, icmp_seq=2 hlim=58 time=25.147 ms
vs.
ping google.com
PING google.com (216.58.216.224): 56 data bytes
64 bytes from 216.58.216.224: icmp_seq=0 ttl=251 time=37.229 ms
64 bytes from 216.58.216.224: icmp_seq=1 ttl=251 time=36.672 ms
64 bytes from 216.58.216.224: icmp_seq=2 ttl=251 time=38.319 ms
I think this is due to my provider (Verizon) being a dick with their peering agreements and the HE.net traffic goes over a less congested pipe than my ordinary v4 traffic.
I had no trouble getting an HE tunnel working, but it does mess up some sites that depend on IP geolocation. Netflix in particular becomes very confused about my whereabouts and refuses to play a lot of content.
My ISP supports IPv6, but I deactivated it.
The reason: https://blog.dave.io/2011/06/vpn-ipv6-privacy/
The reason: https://blog.dave.io/2011/06/vpn-ipv6-privacy/
Leaks are a problem and people are working on it[1] but you could reconfigure your VPN to carry IPv6 traffic, too. At least OpenVPN is capable of it[2].
It's also a bit of an edge case. Browser-level proxying (Tor, SOCKS proxies) shouldn't leak whereas for p2p/torrent it makes more sense to run the client itself on a remote server rather than route traffic through it.
[1] https://leap.se/en/services/eip
[2] https://community.openvpn.net/openvpn/wiki/IPv6#ProvidingIPv...
It's also a bit of an edge case. Browser-level proxying (Tor, SOCKS proxies) shouldn't leak whereas for p2p/torrent it makes more sense to run the client itself on a remote server rather than route traffic through it.
[1] https://leap.se/en/services/eip
[2] https://community.openvpn.net/openvpn/wiki/IPv6#ProvidingIPv...
There's now even an RFC around this problem: https://www.rfc-editor.org/rfc/rfc7359.txt
Your VPN provider is really your primary internet service provider in that case...
How much time pressure are we under to replace IP4 with IP6? Is this something that has to be done in 2 years or 10 years?
It varies.
Some ISPs made sure to allocate rather a lot of addresses around 2010, and have room to grow by allocating more efficiently. The ISP where my colo hosts lives used one /30 per customer at the time (which is a fine, sensible strategy, just not one that saves IP addresses). When one of those old customers leaves, the ISP can use the /30 for four new customers.
Another ISP I deal with has already run out of v4 addresses, and some of its customers only have CG-NAT access to IPv4 today. That ISP already has to optimize many things for low v4 address usage.
Some ISPs made sure to allocate rather a lot of addresses around 2010, and have room to grow by allocating more efficiently. The ISP where my colo hosts lives used one /30 per customer at the time (which is a fine, sensible strategy, just not one that saves IP addresses). When one of those old customers leaves, the ISP can use the /30 for four new customers.
Another ISP I deal with has already run out of v4 addresses, and some of its customers only have CG-NAT access to IPv4 today. That ISP already has to optimize many things for low v4 address usage.
You are under pressure now.
Carrier grade NAT is a nightmare that ISP's will start going down from now. It will be offered as a cheaper option but in fact it breaks how the Internet was designed to work. Think about your external IP being a 10.x.x.x address and you sharing a public address with 100,000 other subscribers. Thinking about how P2P connections like video conferencing would work.
Push for your servers to have IPv6 by default, push for IPv6 at your work place, push for your DNS provider to support IPv6. Always ask any service providers their IPv6 status.
Carrier grade NAT is a nightmare that ISP's will start going down from now. It will be offered as a cheaper option but in fact it breaks how the Internet was designed to work. Think about your external IP being a 10.x.x.x address and you sharing a public address with 100,000 other subscribers. Thinking about how P2P connections like video conferencing would work.
Push for your servers to have IPv6 by default, push for IPv6 at your work place, push for your DNS provider to support IPv6. Always ask any service providers their IPv6 status.
Anyone know what that weird spike was in the first week of October 4?
No idea... a number of us who watch IPv6 traffic stats have been wondering about that spike ever since it first appeared.
The spike does not appear in other data sets like that from APNIC:
http://stats.labs.apnic.net/ipv6/XA
The spike does not appear in other data sets like that from APNIC:
http://stats.labs.apnic.net/ipv6/XA
I wouldn't be surprised if that 1.36% in Ireland was almost solely down to the hosting company I work for.
I really wish the hosting providers here would get their acts together when it comes to IPv6 deployment, but they're really dragging their heels on it. I recently got a VDSL connection from Magnet and while I've a static IPv4 address for the connection, no such luck for IPv6.
I really wish the hosting providers here would get their acts together when it comes to IPv6 deployment, but they're really dragging their heels on it. I recently got a VDSL connection from Magnet and while I've a static IPv4 address for the connection, no such luck for IPv6.
I'm curious about the peaks and troughs in the graph. It seems the graph reaches a peak every week, does anyone know a reason for this?
Hehe this was an exercise question at my university. Look at the peaks again, zoomed in on a week, and you'll see that it's always on the weekend.
This most likely means that more people have IPv6 connections at home (weekend), than they do at their work place (throughout the week).
This most likely means that more people have IPv6 connections at home (weekend), than they do at their work place (throughout the week).
You'll notice the same pattern on browser usage graphs - IE peaks during working hours, every other browser peaks on weekends and evenings.
Weekends. More home users have IPv6 than business users. Comcast and Time Warner are both pretty far along in their IPv6-availability rollout.
(You can also check last Christmas, where there's a bit of an extended peak.)
(You can also check last Christmas, where there's a bit of an extended peak.)
In Germany, Kabel Deutschland, no longer offers ipv4. At least, My router only gets an ipv6 one. (100/6Mb + phone line = 55 eur)
How do you access IPv4 sites? Tunnel?
Some of the carriers who have gone IPv6-only like T-Mobile USA use technologies like 464XLAT to access IPv4 sites. Here's some info:
http://www.internetsociety.org/deploy360/resources/case-stud...
And RFC 6877 specifies 464XLAT:
http://tools.ietf.org/html/rfc6877
and here is even more detailed info from T-Mobile:
https://sites.google.com/site/tmoipv6/464xlat
Regarding DS-Lite, this video from RIPE NCC provides a nice overview:
http://www.ripe.net/lir-services/training/e-learning/ipv6/tr...
Both DS-Lite and 464XLAT are ways that an ISP can be IPv6-only yet still access legacy IPv4 content and services.
http://www.internetsociety.org/deploy360/resources/case-stud...
And RFC 6877 specifies 464XLAT:
http://tools.ietf.org/html/rfc6877
and here is even more detailed info from T-Mobile:
https://sites.google.com/site/tmoipv6/464xlat
Regarding DS-Lite, this video from RIPE NCC provides a nice overview:
http://www.ripe.net/lir-services/training/e-learning/ipv6/tr...
Both DS-Lite and 464XLAT are ways that an ISP can be IPv6-only yet still access legacy IPv4 content and services.
Probably carrier-grade NAT64.
EDIT: Apparently it's DS-Lite: https://news.ycombinator.com/item?id=6818805
EDIT: Apparently it's DS-Lite: https://news.ycombinator.com/item?id=6818805
Can IPv6 become, ironically, the reason ipv4 never dies? Once a majority move to v6 wouldn't that mean a whole bunch of the ipv4 space is being free'd up.
This allows those who never update to actually never update.
This allows those who never update to actually never update.
Once the critical mass is reachable over IPv6, the rest becomes "long-tail" which will eventually be too expensive to bother about.
An extreme example: if an internet user has IPv6 and just uses gmail, youtube and facebook - they can turn off IPv4 right now and not notice anything.
Lee Howard has had an interesting presentation on the subject: https://www.nanog.org/sites/default/files/wed.general.howard...
p.s. Quite a few million of T-mobile's subscribers are also IPv6-only today, just that they use NAT64/464XLAT to connect to IPv4-only services.
An extreme example: if an internet user has IPv6 and just uses gmail, youtube and facebook - they can turn off IPv4 right now and not notice anything.
Lee Howard has had an interesting presentation on the subject: https://www.nanog.org/sites/default/files/wed.general.howard...
p.s. Quite a few million of T-mobile's subscribers are also IPv6-only today, just that they use NAT64/464XLAT to connect to IPv4-only services.
I think there will remain a minority, yes. Probably older devices which still work fine otherwise (especially appliances, sensors, etc). We'll probably see a bunch of such IPv4 LANs behind NAT64 gateways, so that the rest of the 'net can still talk to them.
But I don't think having more free space will make much difference; they can use a reserved IPv4 address (in the 10.* range or so) and have a public IPv6 address configured in the NAT gateway.
But I don't think having more free space will make much difference; they can use a reserved IPv4 address (in the 10.* range or so) and have a public IPv6 address configured in the NAT gateway.
People who adopt IPv6 addresses tend to keep an IPv4 address as well.
Until we see more carriers moving users over to DS-Lite, where their IPv4 usage is NATed https://news.ycombinator.com/item?id=8680759
But if a majority move to IPv6, wouldn't the holdouts have difficulty communicating?
There has to be bridges to IPv4. There will be IPv4 only servers for a long long long time.
Unlikely. It's difficult to remove the last v4-only device from a network. Much easier to just leave the migration at 90, 95 or 99% complete and keep the v4 addresses.
Doesn't IPv6 also mean the permanent death of privacy? Think about it. IPv6 kills all the stupid NAT schemes IPv4 required. Everyone gets a permanent static IP address. Your browser delivers it to every site you visit. It's the ultimate permanent cookie. Of course Google is so happy for this.
No, you don't get a permanent static IP address. That depends on the ISP. And even if your ISP hands out permanent addresses, your devices can change addresses often. Most of my devices do change addresses, and I didn't have to turn it on.
Both v6 and the linux stack are privacy-friendly.
Both v6 and the linux stack are privacy-friendly.
> Both v6 and the linux stack are privacy-friendly.
Yes and no.
The privacy extensions will create new addresses, but they will always belong to the same /64. To my knowledge, TWC will allocate a /64, but there's no guarantee that power cycling your modem will generate a new /64[0]. I believe other ISPs work the same way - they may give you a new /64, but they're not required to and don't guarantee it in the SLA. And most people won't power cycle their modems often anyway, which means they could have the same /64 for months on end.
If we're talking about online tracking, it's very easy for trackers to just throw their hands up and treat all addresses within a /64 as if they represent a single user + device. This isn't completely accurate, but it's no less accurate than IP address tracking with IPv4.
Furthermore, I am unaware of any reliable commercial VPN providers that currently provide IPv6 connections (at least over OpenVPN[1]), so if you have dual-stack connectivity, your IPv6 connection can compromise your privacy even for your IPv4 connection[2].
[0] Technically this is true for ipv4 as well, but due to the relative scarcity of addresses you're less likely to get a pseudo-static ipv4 address.
[1] OpenVPN now supports IPv6 clients, though I don't know of any actual deployments of this. PPTP is IPv4-only.
[2] I think this blog post is sadly still accurate: https://blog.dave.io/2011/06/vpn-ipv6-privacy/
Yes and no.
The privacy extensions will create new addresses, but they will always belong to the same /64. To my knowledge, TWC will allocate a /64, but there's no guarantee that power cycling your modem will generate a new /64[0]. I believe other ISPs work the same way - they may give you a new /64, but they're not required to and don't guarantee it in the SLA. And most people won't power cycle their modems often anyway, which means they could have the same /64 for months on end.
If we're talking about online tracking, it's very easy for trackers to just throw their hands up and treat all addresses within a /64 as if they represent a single user + device. This isn't completely accurate, but it's no less accurate than IP address tracking with IPv4.
Furthermore, I am unaware of any reliable commercial VPN providers that currently provide IPv6 connections (at least over OpenVPN[1]), so if you have dual-stack connectivity, your IPv6 connection can compromise your privacy even for your IPv4 connection[2].
[0] Technically this is true for ipv4 as well, but due to the relative scarcity of addresses you're less likely to get a pseudo-static ipv4 address.
[1] OpenVPN now supports IPv6 clients, though I don't know of any actual deployments of this. PPTP is IPv4-only.
[2] I think this blog post is sadly still accurate: https://blog.dave.io/2011/06/vpn-ipv6-privacy/
Well, I have two consumer DSL connections at home from different ISPs with completely independent infrastructure (a few billable hours pays for a year's redundancy). Both of them behave give me new, unpredictable v6 prefixes via DHCP every 2h/1d.
So obviously not all other ISPs work the way yours does.
So obviously not all other ISPs work the way yours does.
So, you are dependent on the ISP cooperating to give you privacy? What could possibly go wrong? Downvote me all you like guys. This just proved my point. NSA will love IPv6 adoption.
Sure. We're dependent just like we were on IPv4, except that the ISPs' address pools are bigger. The same things can go wrong.
That sounds a bit disingenuous. IPv4 was always on a forced rotation because a) limited address space and b) ISPs wanted to milk customers for static IP charges. IPv6 eliminates a). That leaves b) which isn't really a factor on mobile devices. It really is a permanent cookie if the ISP decides to implement it that way. I can't say I trust AT&T and Verizon after their 'header enrichment' shenanigans.
What do those two ISPs on another continent have to do with my argument?
http://en.wikipedia.org/wiki/IPv6#Privacy
When privacy extensions are enabled, the operating system
generates random host identifiers to combine with the
assigned network prefix
Privacy extensions are enabled by default in Windows
(since XP SP1), OS X (since 10.7), and iOS (since version
4.3).[32][33] Some Linux distributions have enabled
privacy extensions as well.[34]That's why OSes use privacy addresses.
Privacy addresses still come from the same /64 which works a lot like a single IPv4 for home deployments. So from the privacy perspective IPv6 is like giving every home router a static IPv4 address.
Of course, there is no technical requirement to make those addresses static. It's just how they're usually assigned because it's more convenient.
Of course, there is no technical requirement to make those addresses static. It's just how they're usually assigned because it's more convenient.
How come some countries have a negative -10ms *latency?
I think it's latency relative to ipv4. So maybe their ipv4 networks are more congested.
ah yes that would explain it. Thanks
In IPv6, just like in IPv4, you have a firewall. In Linux, you use ip6tables instead iptables, for example. This is what keeps your devices on your network safe. If you were to start from scratch to set up a router with an IPv6 firewall, you'd need just two rules: (1) allow packets in for already established connections and (2) drop every other incoming packet. If you know what you are doing, you can actually set this up yourself. I have, and while educational, it provided no real world benefit.
Most people don't want to bother with using iptables directly, so don't. Get a router that supports OpenWRT and flash it. For most of them, it's a really simple process (my TP-Link let me upload the binary to flash via the web GUI). Why OpenWRT? Well, it's secure and constantly updated, it supports IPv6 natively, and it comes with the IPv6 firewall that is configured in a fashion very similar to how you think of IPv4 (it even rate limits ping requests, etc.). As a bonus, if your ISP doesn't support IPv6, OpenWRT has an installable web GUI component for configuring an IPv6 tunnel. Lastly, even if you don't want IPv6 (yes, I see you there in the back, climbing back under your rock), still use OpenWRT. It seems to have a lot less bugs than commercial router firmware, and is a lot more stable and up to date than DD-WRT or Tomato.
Edit: One other misconception that comes up frequently is that IPv6 means that your privacy is at a more of a risk because your MAC address may be exposed. While in some configurations this can happen, IPv6 has what's called Privacy Extensions: in addition to your more permanent MAC-based IPv6 address (network prefix + munged MAC address), your OS will periodically generate a new random IPv6 address (network prefix + random number). This actually makes it marginally harder to track you since your exact IP address will change frequently, as seen by hosts you access. See http://en.wikipedia.org/wiki/IPv6#Privacy.