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...)
signature.asc
Description: OpenPGP digital signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf