On 22 nov 2007, at 6:46, Christian Huitema wrote:
Well, if I was implementing a new service, I would work very hard to get a public IPv4 address for it, so I don't think this argument works for servers and services for many years to come. It clearly will apply to client systems much sooner. So I'd rather see the problem expressed as: New populations of clients (and p2p hosts) that have no public IPv4 address, but do have plentiful public IPv6 addresses, which need to contact legacy servers (and p2p hosts) that have a public IPv4 address (possibly NATted) but no IPv6 capability.
What P2P hosts are we speaking of, exactly? As far as I know, there are very few PC-class hosts that cannot now run some form of IPv6, using a transition technology like Teredo or 6to4. P2P applications are thus very likely to use that.
There are two types of peer-to-peer: the BitTorrent model, where you don't really care who you talk to because multiple peers have the same resource. As long as there is a reasonable group of dual stack peers there's no need for IPv4 and IPv6 peers to communicate. But with the VoIP model you need to be able to talk to any particular peer so here it's useful to have a way to make IPv6 peers talk to IPv4 peers and vice versa.
Also, users could be running services that aren't necessarily peer-to- peer applications. For instance, Apple's "back to my mac" or similar.
I suggest that we limit the scope of the problem to enabling IPv6 only hosts to contact legacy IPv4 servers, assuming that these servers in fact have a global IPv4 address. Smaller problems are easier to solve...
Doing that in the requirements phase would be too soon, in my opinion. If you look at http://www.ietf.org/internet-drafts/draft-van-beijnum-modified-nat-pt-02.txtsection 4, you'll see that providing access from IPv4 clients to IPv6 services is arguably simpler than the other way around...