On 2007-11-24 00:27, David Miles wrote:
On 22/11/2007, at 4:46 PM, Christian Huitema wrote:In addition, as IPv4 public address space is depleted, it will no longer possible to access to IPv4 public addresses, making dual stack nodes even less attractive.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.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...I'm strongly in favour of Dual Stack for this requirement - again, why introduce translation between IPv6 hosts and legacy servers when every OS I can think of that supports IPv6 also supports IPv4 through dual stack.
Because, as already noted, some IPv6-capable hosts (whether servers or P2P participants) may find themselves stuck in an IPv4-only world. I'd guess that many Vista hosts are in this situation today.
My view is that Dual Stack adequately addresses the need for continued IPv4 support using existing techniques such as NAPT. After all, if we come up with a "translation" protocol for IPv6 to IPv4 then we have not absolved ourselves from solving the issue for non-IPv6 hosts. In an IPv4 address depleted world, non-IPv6 devices still need to work! Why have NAT (in the service provider) for IPv4 hosts, and IPv6-to-IPv4 translation for other hosts (likely both existing in the same household)? Is this not adding complexity for no obvious business benefit?The only scenario that I can see that we should at least discuss, is a day when IPv4 addresses are scarce to the point that one cannot assign a server a public v4 address, but we can assign it an IPv6 address. In this case an IPv6 host can communicate with the IPv6 server without issue, but an IPv4 client cannot. I have always wondered why we are so fascinated with NAT64 instead of the reverse, NAT46? Even if we did have NAT64 there is still a form of NAPT not dissimilar to today's IPv4 implementations, so why not just use NAPT in the service provider with Dual Stack?I'm all for limiting the scope as suggested, but I would like to table the issue of a legacy IPv4 host wishing to connect to an server that has a valid IPv6 address. Ie, an unsolicited inbound session from the IPv4 "client" to an IPv6 "server".Does anyone consider this a reasonable scenario to consider?
Absolutely, that is the inbound scenario in the Shanti draft, for example. Brian