IPv6 really isn't that difficult. It only takes a few minutes to get a free IPv6 address from a tunnel broker and add it to your server. My websites and email were all dual stack less than 24 hours after I started looking into IPv6 for the first time. I wrote a blog post about it last year:
Congratulations. Now more people are unable to access your website and email because of known bugs with dual stacks than are likely to access your website and email through ipv6. The main issue are people whose setup says that they will connect preferentially via ipv6, who try to connect because their operating system has support for it, but whose IP provider does not have support.
Going dual stack means approximately 1 in 2000 people can't visit my website. It is a simple tech blog. I am ok with those figures. Other sites obviously wont be.
A free tunnel broker isn't going to support the traffic of something like google. And an issue Google has previously run into is, clients getting the incorrect DNS entry and trying to connect across to a ipv6 interface instead of ipv4. This is one of the reasons why google had/has that ipv6.google.com dns name.
If I wasn't clear, I wasn't suggesting that massive websites use free tunnel brokers.
I was suggesting that geeks set up their own services with ipv6 capability in order to learn how it works so they know what to do when it becomes more important.
So I'm on Toredo, which means IPv6 works, but it says I can't visit IPv6 websites, which I understand to be a DNS issue. Any hints on how to get that working?
Google is selective about exposing IPv6 DNS entries. Your ISP has to be in the Google IPv6 program which means that Google trusts your ISP to provide quality IPv6 connectivity. Basically, Google don't want half-assed IPv6 networking setups tainting their brand as unreliable if for instance Bing works (having only IPv4), but Google is slow or inaccessible.
It's understandable from a marketing point of view, but IMO a pretty coward stance on employing new technology. I'm using Google services over IPv6, but the reason I can do that is because I run my own bind instance and have specifically added the Google IPv6 forwarding entries:
Should you have IPv6 and bind, here is what they look like:
zone "google.com" IN {
type forward;
forward first;
forwarders {
2001:4de0:1000:a4::2;
2001:4de0:1000:a3::2;
};
};
Other than that, reasons for not reaching IPv6-sites, even if you have IPv6 enabled is that (at least) Chrome is very selective about IPv6 support. It may accept IPv6-only sites if the position of the moon is right relative to the suns orbit around the milky way.
With Firefox this isn't really an issue, but Google has tried really hard to avoid IPv6 being used with Chrome. For instance: If you are on a tunnelled IPv6 connection (i.e. non-native, like teredo) it will attempt to detect this and block IPv6-connectivity because Google has chosen for you that this may provide an inferior web-experience with higher latency compared to plain IPv4, if available.
Google's IPv6-efforts so far, while I could give them credit for at least have taken a few baby-steps, is by far the most cowardly I have seen anyone take. I find it very hard to applaud them.
Indeed. I wish, just like for Firefox, there was an extension which could tell me what protocol I am using.
As far as I know, Firefox does not discriminate nor positively favor neither IPv6 or IPv4. So far, this is what has given me the best IPv6 experience, and I'm very disappointed Google/Chrome has decided to do their best to conceal from the internet that there are users out there, and that they are ready.
IPv6 deployment is largely a chicken and the egg type of problem and IMO this decision doesn't really help.
Unfortunately this is true of 'localhost' when you have no internet connection if you don't pass the '--enable-ipv6' flag to Chrome. Oddly enough it also happens for 127.0.0.1, which it shouldn't be doing DNS lookup for at all.
I'm wondering if one day, the real necessity to switch to ipv6 fast (after years of experiments) and the fear for possible connectivity issues will create a y2k effect among the population...
Related: The Germany-based IT book and magazine publisher Heise (http://www.heise.de) did this back on 2010-09. The test has been such a success (practically no problems, for their share of readers, though) that they made that permanent. They wrote that those Big Guys had asked them on their experiences. Maybe this actually works out. (Source, German: @ http://www.heise.de/newsticker/meldung/Globaler-Test-fuer-da...)
The Norwegian companies A-Pressen Digitale Medier (http://www.apdm.no/) and VG Multimedia (http://www.vg.no/), both news publishers with non-technical audiences, had similar experiences. The IT group that helped them set it up published the results of their experience and brokenness testing here: http://fud.no/ipv6/
Pretty accurate. IPv6 is flawed in ways that make it non-upwards-compatible with IPv4, so a smooth transition is impossible. Oh well, there is enough stuff on the internet already.
DJB's proposal ignores the fact that v4/v6 translation requires new equipment and it wasn't clear where these boxes should be located in the network or who would pay for them. What is now called NAT64 is pretty similar to DJB's proposal and a few ISPs are planning to try it. Most people still prefer variants of dual stack, though.
"The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space." -- djb (emphasis mine)
It's true that it would have make sense to embed IPv4 address space into IPv6!
It makes sense only in the abstract. Once you look at the details of how IPv4 was implemented, it is clear that such an idea makes no sense at all. All IPv4 devices and software are hard coded to use 32 bit addresses. No more and no less. No amount of "design" can make 128 bits fit into 32 short of having designed IPv4 with bigger (or variable length) addresses in the first place.
To have an "extended IPv4 space" you must change all hardware and all software to be aware of that extended space. Hardware/software/networks that haven't been changed yet won't be able to use or route "extended" IPv4 packets. Such a situation has all of the same problems as IPv6.
Given those fundamental limitations plenty has been done to make inter-operating between protocols work as well as possible.
The ::ffff:/96 space was set aside as the "IPv4 embedded in IPv6" space (http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses) so that IPv6 aware software can talk about IPv4 addresses. Though cannot talk to them because there is no way to encode the 128 bit return address in the 32 bit field.
IPv4 was extended with the protocol 41 header option to allow two IPv6 systems to exchange IPv6 packets over the existing IPv4 network (this is how 6to4 and teredo/6in4(tunnelbroker) systems work). This effectively means that anyone with a public IPv4 address (or in the case of teredo even some systems behind NAT4) can talk to IPv6 machines albeit through translation mechanisms that can hurt performance.
edit: Actually, now that I think about it, accessing IPv4 internet from IPv6-only LAN should be almost trivial. Lets say you happen to have 3000::0 IPv6 network completely unused, which also fits the entire IPv4 address space. Then you could configure your DNS server to respond to AAAA queries for domains that have only A records with an corresponding IPv6 in your free block. Ie news.ycombinator.com(174.132.225.106) would become 3000::ae84:e16a or something like that. Then your router which is default gw for the hosts receives a package destined to that special network, it takes the payload and puts it into a IPv4 packet with destination decoded from the IPv6 address.
It seems kinda obvious approach, wouldn't require any modification of the hosts or to the internet. Of course I don't know why anyone would want to run a IPv6 only LAN instead of mixed v4/v6, but maybe there is some reason to. Are there some problems that I haven't noticed? Surely someone must have thought about this before.
Effectively they give devices IPv6 addresses only and run a DNS server that makes up "fake" IPv6 addresses for all of the v4 only DNS records. It works well except when applications embed IPv4 literals (as they won't go through the DNS system and get translated)
Off the top of my head all Apple Airport Express/Extreme/Time Capsule routers, DLink 601/655/855, linksys WRT610N/E3000. All support IPv6, most of those let you configure the router as 6to4 or 6in4 (tunnelbroker, etc) tunnel endpoint as well. The DLink ones even support a stateful DHCPv6 server to provide specific v6 address ranges to your LAN clients.
The support on the most recent revisions often isn't just limited to firmware either. The Dlink routers have IPv6 ready logos on the box and instructions for IPv6 features in the manual. You can pick these routers up in your local Best Buy or Office Depot and the v6 support is not limited to the high end ones either.
I am sure there are more than those that I have listed, they are just the ones that I have personally used for home IPv6 stuff.
Sorry, I meant DIR-615/825 not 655/855. You are correct, the 655 does not support IPv6 at the moment. According to Dlink support forums in 2009 there were plans for the 655 to get upgraded but I haven't heard anything since.
Note: the way Dlink has done the IPv6 upgrades on the other models is by releasing a new hardware revision. So DIR-615 Rev C,D, and E supports IPv6, but Rev A and B don't. =\
DD-WRT firmware supports it in certain firmware versions. A little start up script hacking is required, but, you can setup a ipv6 tunnel through hurricane electric or one of the other tunnel brokers.
Here at Carnegie Mellon University, we're allocated routable IPv4 addresses (and real DNS entries) for each MAC address you connect to the campus network with.
As far as I can tell, I have zero support for IPv6. Autoconf doesn't work at all, and I'm unable to find any documentation about it. Sigh.
According to http://twitter.com/#!/IPv4Countdown, we will run out of IPv4 addresses in about a month. Won't June already be a few months past when we run out?
That counter is when global registries have allocated everything, not strictly when all useable addresses are in use. IPv4 addresses will never "run out", they will just get more expensive and complicated to use until the point where IPv6 is cheaper and easier. IANA exhaustion is just one big milestone along that path.
it's not as easy as that, and not very new idea. Some RIRs (Regional Internet Registries) do not allow that. you would need to find some legacy space to do it, which it may be hard. and then some buyers.
also you only have a few years to recover your investment, by the time ipv4 is finished (not the IANA pool, but the actually stock from rirs), probably ipv6 would be a reality.
Google: “Though IPv4 plays an important role in the Internet, as our goal is to enable open innovation, support for the protocol will be removed and our resources directed towards completely new technologies, such as IPv6.”
It's satire. In some ways, the reasoning that led Google to drop support for H.264, if taken to extremes, could be used to support the logic of dropping IPv4. I was merely pointing out, in a funny way, the parallel between the two situations, and the absurdity of the original H.264 decision.
https://secure.grepular.com/Setting_up_IPv6_is_Easier_Than_Y...
If you get a cert error it's because the certificate is signed by cacert.org and several major browser/os combos don't have their root yet.