World IPv6 Day: firing up the engines on the new Internet protocol(googleblog.blogspot.com)
googleblog.blogspot.com
World IPv6 Day: firing up the engines on the new Internet protocol
http://googleblog.blogspot.com/2011/01/world-ipv6-day-firing-up-engines-on-new.html
47 comments
Here's a start-up idea: an IPv4 address market/exchange (unless something like this already exists)
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.
https://www.arin.net/resources/transfer_listing/
(IPbay does have a nice ring to it, though.)
(IPbay does have a nice ring to it, though.)
A handy quick test of your current IPv6 readiness is to try Google IPv6: http://ipv6.google.com/
Sadly it doesn't work for me - for curiosity's sake I'm now going to try via Lynx from my servers :)
Sadly it doesn't work for me - for curiosity's sake I'm now going to try via Lynx from my servers :)
http://test-ipv6.com/ gives you a bit more info about exactly what is working and what isn't in regards to your v6 connection.
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:
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.
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;
};
};
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.
Lets hope "World IPv6 Day" goes smoothly enough that they can drop some of those restrictions. =)
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.
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.
There could some issues for home users such as me(Rogers internet):
Error 105 (net::ERR_NAME_NOT_RESOLVED): The server could not be found.
Which is probably related to dns resolution.
Error 105 (net::ERR_NAME_NOT_RESOLVED): The server could not be found.
Which is probably related to dns resolution.
ERR_NAME_NOT_RESOLVED is Chrome's DNS Timeout. The same error will occur if you navigate to a webpage without an internet connection.
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.
or go to http://www.kame.net/ and see the dancing kame!
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:
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.
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.
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.
See http://getipv6.info/index.php/Customer_problems_that_could_o... for more potential problems you've created.
Of course this is a kind of problem that needs to get fixed before ipv6 can be broadly adopted. Which is why this ipv6 days is going to happen.
See http://getipv6.info/index.php/Customer_problems_that_could_o... for more potential problems you've created.
Of course this is a kind of problem that needs to get fixed before ipv6 can be broadly adopted. Which is why this ipv6 days is going to happen.
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.
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.
Thanks for the clarification :)
it seems my isp won't provide native ipv6 addresses until they are somehow forced to... -_-
Now, if only my router supported IPv6. Sadly, it doesn't seem to come out of the box on any home-oriented routers.
This is actually not true anymore.
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.
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.
I have a fully-upgraded D-Link DIR-655 rev.A (unless there's some other prefix before the 655 you mentioned) and it does not seem to support IPv6.
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. =\
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.
On any?
My WRT610N ($160 on amazon) seems to work fine for ipv6.google.com and I have not configured anything.
I would hope all new linksys are similar, but a quick search makes it look like the WRT300N does not support v6.
My WRT610N ($160 on amazon) seems to work fine for ipv6.google.com and I have not configured anything.
I would hope all new linksys are similar, but a quick search makes it look like the WRT300N does not support v6.
I also have an WRT610N, but I'm failing tests here:
http://test-ipv6.com/
I can also see ipv6.google.com, but I know my ISP doesn't do IPv6.
I can also see ipv6.google.com, but I know my ISP doesn't do IPv6.
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...
Reminds me of the busysignal I'd get after dialing into Prodigy. "Please wait while we allocate an IP address for your internet connection."
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.”
[deleted](1)
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.
Ah, I see. Thanks for the explanation! I assumed that this was counting how many are in use/assigned, versus simply allocated.
After roughly 8 years, how do DJB's predictions/comments hold up on ipv6?
http://cr.yp.to/djbdns/ipv6mess.html
http://cr.yp.to/djbdns/ipv6mess.html
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'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.
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.
Kinda like http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses ?
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.
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.
This is referred to as NAT64/DNS64 (http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#NAT6...) and is the strategy many mobile phone networks (such as T-Mobile USA) are taking.
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)
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)
What you're describing is basically NAT64.
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/
[deleted]
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.