Introducing Pseudo IPv4
blog.cloudflare.com
blog.cloudflare.com
https://twitter.com/bertjwregeer/status/470243728473325568
Was my Tweet to Stackoverflow regarding the issue.
Here is the paste of the symptoms seen: http://paste.ofcode.org/XQGqerxCNXwYsHDQMZ3aja
This meant that until I reported the issue to Cloudflare/StackExchange that people using IPv6 were UNABLE to access those resources needed to load the site (the server would hang indefinitely, so happy eyeballs did not work!). In the case of StackExchange on Centurylink that meant that CSS and other resources did not load, for my site (http://defcne.net/) that meant my site didn't load at all!
I absolutely love Cloudflare, but to me it is inexcusable that there is no monitoring to verify that these issues don't exist. It took me filing a report for them to fix the issue.
Ultimately it came down to this:
"We had recently been experiencing IPv6 routing issues with one of our upstream providers for some of our data centers which may have contributed to the issues you had been seeing. We've since disabled transit for that provider to temporarily work around the issue."
Yet this meant that my site/StackOverflow and countless other sites using Cloudflare were offline (if the customer has IPv6 enabled) for almost a week (first report from customer using CenturyLink, me trying to figure out what is going on, to CloudFlare fixing the issue).
Sadly, in my case, this is untrue. If I enable v6 on my Comcast home connection, I see routes with consistently higher latency--around 50ms more for paths within the U.S. such that even a 200 mile destination (HSV => ATL) is ~70ms away.
(I'm sorry sir/madam for your inconvenience)
They have a landing page[0] that hints at the possibility, but I've never seen anything or heard anyone actually say that IPv6 is coming to residential customers.
[0] http://www.verizon.com/Support/Residential/Internet/HighSpee...
I haven't bothered posting on the Comcast forums. I simply disable IPv6 and get on with my life. Maybe I'll give it a try in another few months.
Are you sure that you're not running over a Teredo tunnel? (Is the IPv6 address you're handed in the 2601::/28 range [native IPv6 for Comcast], or is it in the 2001:0::/32 range [Teredo tunnel]?)
Does some of your networking hardware handle IPv6 poorly? What happens when you plug in a IPv6-enabled computer directly into your cable modem?
I work on the IPv6 team at Comcast - please email me with details... nathan (underscore) owens(at)cable(dot)comcast.com
Thanks, Nathan
Thanks, Nathan
Which router do you have, and which firmware version? Which OS/Browser are you testing on?
Thanks, Nathan
I think what might be kind on Cloudflare's side is to add a secret domain-specific salt to this md5 hash, but I'm by no means a crypto person.
(edit) eastdakota and billpg below both pointed out that to carry out an impersonation would require connecting to Cloudflare with the correct IPv6 address. This is probably the biggest hurdle, so feel free to ignore what I wrote above.
Even that possible vulnerability (if I can even call it that) would be stopped if they (Cloudflare) included a secret salt in the hash so the only way to know which class E a particular IPv6 address has would be to try it out and observe the connection from the other side.
Feel free to argue the actual argument presented.
I noticed class E address space in my gmail activity log years ago, and a wink from a googler implied this is what they were doing. Nice to have confirmation.
That's pretty cool. However, we can only do this if we get over the chicken-and-egg problem, which is why it's important you enable IPv6 and encourage others to do so.
Yes, it's easier to hole punch, but a webserver won't do that.
And if you're manually configuring a firewall, I'm not sure "allow port 80 <someIPv6>" is any easier than "forward port 80 to <someipv4>.
What am I missing?
That allows me and the people I know to connect to each other's machines in a way that wouldn't be possible with IPv4 and NAT. I can be at my brothers and type \\[fqdn] in explorer and it will just work. To me, that is the way the internet was meant to function from the beginning.
Truth is that for most users, NAT today is almost always synonymous with a firewall that has deny in, allow out policy.
10+ years ago, a lot of folks often connected their machines to the Internet in the way you specified. You could go around scanning people's systems, viewing their fileshares and so on. NAT "fixed" a lot of that.
Second, if ISPs are willing to keep records of IP-address-to-customer mappings, it's not much of a stretch to add TCP/UDP ports to those records as well.
Not necessarily. I've configured my IPv6 firewall to block all the things except for specific ip:port pairs. I didn't feel like leaving my network totally open.
Sure there is NAT and various other things carriers and ISPs can do, but that will increasingly be the slow path, and possibly even charged for.
You can put your head in the sand, only to have this issue bite you badly and urgently one day, or you can start now slowly but surely making sure everything appropriate is done. For example you can make sure purchases of equipment and software claim to work correctly (how will your VPN work?), do whatever training is necessary etc and gradually add IPv6 to your infrastructure and clients.
Consider an ISP with Native IPv6 and NAT'd IPv4. (T-Mobile and Verizon Wireless are specific examples in the USA.) When you dual-stack your server, that traffic no longer needs to traverse the NAT, so users may see better performance.
There's no way to avoid NAT in general, because there simply aren't enough IPv4 addresses to go around, but ISPs should be able to deploy NAT equipment with the assumption that the operational costs will decline over time as IPv6 becomes more popular.
Putting stateful NAT boxes everywhere is antithetical to the concept of a free, neutral network, so we should all be striving to make the alternative viable.
[edit] I originally did this with a 24-bit rather than 28-bit space, so my numbers were way to low.
I looked into enabling that for virtual networks in my app ( www.zerotier.com ) and quickly discovered that Microsoft Windows has hard coded these IPs as unusable. On a Windows box the IP stack will absolutely refuse to talk to the 240 block. I spent a few weeks looking for a workaround and could not find one, but I did talk to someone who used to work in MS and he confirmed to me that it was a hard-coded prohibition.
The entire Windows networking stack from top to bottom is a tangled mess of pain.
Not having a convenient way to monitor the IPv6 side of things is my last reason for not enabling IPv6.
I'm not sure how we can talk AWS into supporting IPv6 :)
Edit: This will happens with anything which blocks Facebook frame, but not Facebook script.
i fix it by right clicking and choosing inspect element and deleting the node.
i believe the issue i have is caused by barracuda blocking the iframe's content.
||connect.facebook.net^$script,third-party
Edit: or really, just: ||connect.facebook.net^$third-party(I'm really glad they did this, because at 4chan's patented "SOON™" dev pace, it'll take us another decade to add native IPv6 support.)
The real problem with the original article title is that it is linkbait (grand claim about a controversial topic) and misleading (there is far from universal agreement about this), and so violates both of HN's guidelines about titles. Therefore it needed changing, and when doing so we try where possible to take language from the article itself rather than inventing something of our own. A subtitle is often a good choice, because it's often what the article would have called itself if it weren't trying to be sensational, and that seems to me to be the case here.