Jeroen Massar writes:
I only need 1 IPv4 IP which can do HTTP/SMTP/NNTP/FTP/etc.
proxy/gatewaying/etc. to the IPv6 world. Neeto huh?
Completely uninteresting. Every public server still has an IPv4 address,
so your network is functionally identical to a standard IPv4 NAT setup.
Meanwhile, despite heavy use of NAT, the available IPv4 address space
seems to be disappearing. How do you propose solving this problem?
But one time in the future we won't have any IPv4 addresses any more
and everything will be IPv6,
Aha! Now _that_ would be neat. If www.company.com can be safely deployed
on an IPv6 address, the problem described above will vanish! Wonderful.
There are other reasons that, as a programmer, I'd like to see this.
But how exactly do we get to that situation? The current situation is
that you'd have to be an idiot to rely on IPv6 for www.company.com. How
do we change this?
The underlying fact is that millions of Internet computers won't connect
to, and won't accept connections from, computers on IPv6 addresses. How
do we change this?
These fundamental aspects of the IPv6 transition have been horribly
mismanaged. Three examples:
* Many network stacks and routers are providing ``IPv6 support,'' but
this ``support'' doesn't do anything unless the sysadmin takes time
to configure it.
A small amount of extra effort would have provided an automatic
IPv6-over-IPv4 tunnel using an IPv6 address computed globally from
the IPv4 address.
* A typical single-address server---for example, a small DNS server
answering queries on 131.193.178.181---has to set up a second
socket and pester the sysadmin for a second address if it's going
to answer IPv6 queries.
(Even if IPv6+IPv4 wildcards were supported by all IPv6 stacks,
they would be unacceptable for these applications. Many machines
have, for example, a DNS cache on one address, and a DNS server on
another address. Same for SMTP servers.)
A small amount of extra effort would have provided a unified
IPv6/IPv4 socket that accepts connections on 131.193.178.181 _and_
on the automatic IPv6 address described above, allowing these
common servers to support IPv6 with a minimum of fuss.
* We're now being told that IPv4 sysadmins ``SHOULD'' take the time
to set up AAAA records for all their machines.
A small amount of extra effort would have provided connectivity
from IPv6 clients to existing A records, through the tunnels
mentioned above.
In short, the transition cost is much larger than it needs to be. People
here seem to have lost sight of the problem that motivated IPv6 in the
first place.
---Dan