Game theory and IPv4 to IPv6
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Game theory and IPv4 to IPv6



The problem is that until IPv6 has critical mass it is much better to be on IPv4 than IPv6. 

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.

An actor can be in one of several states:

Unconnected
IPv4 connected with own address
IPv4-NAT connected with NAT address
IPv4/IPv6 connected Dual stack
IPv4-NAT/IPv6 connected Dual stack
IPv6 connected

There are certain costs associated with the various transitions. 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.

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.


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.

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.

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 de______________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.