Hallam-Baker, Phillip wrote: > The problem is that until IPv6 has critical mass it is much better to be on IPv4 than IPv6. Yes, because of latency, No because of NAT's. > If there are any grad students reading the list take a look at the game theory literature > and apply it to the transition. Assume that it's a rat-choice world and that each actor > follows their best interest. [ postgrad hat on ;) ] There is a reason why companies like Demonware (http://www.demonware.net/) exit, they exist solely to provide for a cleanup of the IPv4 mess with NAT's by providing a stable stack that allows them to get around most NAT issues by using mechanisms like STUN. Note that MS has given a very lucrative way of solving this problem by providing Teredo support; games and other programs simply use IPv6, all the NAT issues get solved automagically by Teredo. > There are certain costs associated with the various transitions. Latency being the number one problem. Every millisecond extra causes annoyance to users. Unfortunately due to the state of deployment of Teredo relays and other similar techniques these are not usable (yet). The quake approach: client<->server works though. P2P is out of the question in many of those cases though. > The benefit of being in the IPv4 or IPv6 network is proportional > to the size of the networks. > > I don't have time to run full simulation runs but my preliminary > trials suggest that IPv6 is not relevant to the IPv4 exhaustion issue. IPv4 will run out either way. IPv6 won't slow it down for a even a day. Most, if not all, people using IPv6 also have IPv4 connectivity. IPv6 connectivity in general is non-NATted, while IPv4 is behind a NAT. Want to connect to that box behind the NAT? Just use IPv6 and problem solved. Some people tend to just throw around VPN's to those places though. > The reason is that the participants are all going to cluster into > IPv4/IPv6 or IPv4-NAT/IPv6, there is no incentive I can see to transition > to the pure IPv6 state and release the IPv4 addresses. The whole idea of transition is dual-stack. Some people will be on IPv4, others on IPv6. Servers and gateways (SMTP style) will connect them. For instance if you have a IPv6 enabled Quake server (thanks Viagenie) then IPv4 players can also connect to it. > Unless you assume that there is a very considerable value to IPv4 over > IPv4-NAT all that happens during address exhaustion is that larger and > larger proportions of the net disappear behind NATs. In effect you end > up with the two speed Internet we want to avoid. No, there is no considerable value of IPv4 over IPv6. There is a considerable value of IPv4 over IPv4 NAT though due this the simple concept called End-To-End, which with IPv6 gets restored so that hosts at least get their own IP address again, avoiding all the rattraps introduced by NAT's. Then again, firewalls can block those people off also again, but that is then the network policy, not because they can't at all do it. (Don't play games at work folks ;) > Rather than fight the dynamics of a market with a billion participants > I believe that we should embrace them and remember that taking IPv4 to > end of life is not exactly an unacceptable outcome. The key is to channel > people into IPv4-NAT/IPv6 rather than IPv4-NAT. It also depends on game companies. They should make their games IPv6 compliant so that they at least support it. I am explicitly not saying that they should do IPv6 per default as that will hurt performance in all the cases where quality IPv6 connectivity is unavailable. A toggle to enable it though would be a great step forward. Servers supporting it on the public Internet will then be a second step. > The way that I would go about this is to introduce a gold standard for > next generation gateways that provide other features that the consumer > is likely to consider desirable. Like being maintenance free, working > without the complaints and setup time that current devices require. Greets, Jeroen (hoping that Enemy Territory - Quake Wars supports IPv6...)
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf