IPv6 Adoption Statistics(google.com) |
IPv6 Adoption Statistics(google.com) |
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.
> 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.
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 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.
So if in your country some ISPs are too slow to roll out IPv6, may be they have plans worse.
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.
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.
They plan to have all up-to-date modems provisioned with IPv6 before the end of this year.
Telenet followed somewhere last year, and Belgacom (biggest) followed this year (only on new modems though).
I'm not worried, I just want to have ipv6 access.
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.
There is still the occasional delay, but its similar to the ipv4 service from Comcast.
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.
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.
The reason: https://blog.dave.io/2011/06/vpn-ipv6-privacy/
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...
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.
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.
The spike does not appear in other data sets like that from APNIC:
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.
This most likely means that more people have IPv6 connections at home (weekend), than they do at their work place (throughout the week).
(You can also check last Christmas, where there's a bit of an extended peak.)
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.
EDIT: Apparently it's DS-Lite: https://news.ycombinator.com/item?id=6818805
This allows those who never update to actually never update.
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.
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.
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.
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.
Now consider source routing.
Yup.
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.
If you are running IPv6, get a nice OpenWRT router, where the firewall is enabled by default.
Unfortunately it's going to take a while until it's widely supported.
Maybe OSes will need to stop assuming their underbellies can be soft and implement some real host security.
Naaahhh... hell will freeze over first.
Everyone using Verizon Wireless with an IPv6 capable device is using IPv6. It's behind some sort of carrier grade proxy, but is IPv6.
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.
It should give you your mobile's IPv6 address.
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.
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.
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.
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.
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.
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.
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.
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/
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]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.
http://www.worldipv6launch.org/measurements/ gives a per-AS breakout, with the %%% being the massaged number as seen by the content-provider participants.
OS-level firewall, I guess? Which maybe you should probably have anyway?
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.
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.
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.
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.
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.
So obviously not all other ISPs work the way yours does.
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...
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)
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.
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?
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.
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.
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.
Yep this was exactly my point