Slashdot Mirror

5. Mobile phones - Android 2.0 supports v6, and given that Apple seem to support v6 quite well on a lot of devices I presume iOS probably does too. So nothing new needed here, it just requires a v6-enabled network for them to connect to.

iOS does indeed support IPv6.

Admittedly there are sometimes issues combining VoIP and NAT.

VoIP is one of the most obvious applications for IPv6.

7. Games consoles - like VoIP phones, they are probably talking to a single existing server so they can continue to do IPv4 on a dual-stacked network.

Modern game consoles aren't that big of a concern, as typically the OS and network protocol stack live on the game media itself, and not on the hardware. Old games won't be magically upgraded to IPv6 support, but then again online support for old games isn't all that reliable anyhow. New games that wish to support IPv6 will simply include the necessary protocol stack drivers on their game media. Online features built into the consoles themselves can be handled via a firmware update. The Playstation 2 has IPv6 support (according to this

, it's part of the Standard Developer Kit) -- I would expect that newer consoles also have support in their development kits, even if developers aren't currently taking advantage of it.

Yaz

I wonder what exactly they are trying to achieve by this experiment

The purpose of the experiment is to see what problems actually appear.

If there is a fallback to IPv4 then it there be just a delay.

I expect Google know this - they recently implemented happy eyeballs in Chrome, and I believe similar functionality is also in Safari.

How will Google know about any of that?

See IPv6 in Google - A Case Study (PDF) for an idea as to what Google are already measuring, and how.

To quote an article I once read that addressed what you are saying:

• NAT breaks globally unique address model
• NAT breaks address stability
• NAT breaks the Peer-to-Peer model
• NAT breaks some security and QoS applications
• NAT introduces hidden costs (applications and operations)
• NAT inhibits development of new applications

The long and the short of it is that NAT is only a band-aid... it is not a scalable solution. NAT can only be "good enough" as long as the above issues remain unimportant to a majority of people.

Yes, you can have the very same server answer IPv6 queries as well as IPv4, you just need to add IPv6 interface to the server and make sure the particular server software knows how to bind to IPv6 address.

The particular ISOC survey document which started this thread has a fairly long list of resources at the end of it which might be helpful, but here's a few to get you started: http://www.6diss.org/, http://www.getipv6.info/ and http://www.ipv6tf.org/

The increased number of potential IP addresses is the least interesting and least relevant reason, though it is the most often mentioned in the press. Such a disproportionate amount of words is wasted on the IP range non-issue that I some times wonder if there isn't an intention to draw attention away from the real issues above.

Also news posted at the IPv6 Cluster.

By the way, a new tunnel broker is available here, also with Spanish instructions at 6SOS.

Also news posted at the IPv6 Cluster.

By the way, a new tunnel broker is available here, also with Spanish instructions at 6SOS.