D. J. Bernstein <djb(_at_)cr(_dot_)yp(_dot_)to> wrote:
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.
You can't call a new phone which can handle 128 numbers long
phonenumbers with an 'old' phone supporting only 32 numbers now can you?
And calling an old phone from a new phone will require a gateway system
which handles the old phone and the new phone.
But I already said that a couple of times.
Meanwhile, despite heavy use of NAT, the available IPv4 address space
seems to be disappearing. How do you propose solving this problem?
We don't. And if you look at the real numbers (free IPv4 space) there is
just enough IPv4 space left for the transition period between IPv4 and
IPv6.
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.
Please read Itojun's excellent "Implementing AF-independent application"
at http://www.kame.net/newsletter/19980604/ ) which reveals most
answers.
Maybe we will once see a 'native-tree' qmail supporting IPv6 or even
better AF independence, though it has ip_address struct ? :)
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.
Well duh.... don't you have to configure a IPv4 router ?
But with IPv6 this is easier, just config your router to do rtsol's and
accept rtadv's from it's uplinks et tada it's configured.
Now you only have to give each downlink a portion of the IPv6 space it
gets from it's uplinks.
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.
That's where 6to4 is for (2002:<ipv4>::/48) (RFC 3056).
For microsoft's stack that can easily be done by setting up the 'client'
host:
- Install the IPv6 stack (on XP this translates into: 'start->run "ipv6
install")
- 6to4cfg -b
et tada your done and every other stack also has this kind of
ease-of-use.
* 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.
An IPv6 aware application could simply listen on [::/0]:<port> and
accept all connections there.
All depends on how/where one writes it's program.
For the 'IPv6 address pestering part', if it's a DNS server it probably
falls under the authority of the admin,
which if that admin setup his network correctly and did it the easy way
the server would simply rtsol an IPv6 address.
(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.)
Would yet-another socket matter then ? ;)
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.
That currently depends on the stack.
Some stacks are mixed IPv4/IPv6 and some are IPv4&IPv6 in one.
Thus on some platforms/stacks a programmer needs to bind() only to IPv6
(and IPv4 comes in with the mapped way ::ffff::/96)
and on some to IPv6 and IPv4. (Yes, this is a not so very handy
situation but that's why there is that ./configure command ;)
* We're now being told that IPv4 sysadmins ``SHOULD'' take the time
to set up AAAA records for all their machines.
If you don't you simply won't have (easy) connectivity to the IPv6
world.
And today it's SHOULD, in a year or ten (or something ;) your boss says:
MUST.
Also if you don't want to do IPv6 then simply don't... but don't come
crawling back when you are to late with it.
Though as it really isn't that much work, except for some network
planning that shouldn't be a big problem.
A small amount of extra effort would have provided connectivity
from IPv6 clients to existing A records, through the tunnels
mentioned above.
NAT-PT... (RFC 2766):
"route -A inet6 ::ffff::/96 <nat-pt-gw-IPv6-address>" on your IPv6 only
machine.
done...
In short, the transition cost is much larger than it needs to be.
Which 'costs' ?
The biggest 'cost' is the hardware, which you most of the time already
have for IPv4.
'Simply' upgrade your existing routers to support IPv6 et tada...
Or setup an *BSD/Linux/Solaris/etc... box and let that create a tunnel
into the IPv6 internet and have 'native' IPv6 on the LAN/WAN...
People here seem to have lost sight of the problem that motivated IPv6
in the first place.
You mean the size of the address space?
You mean the easy of management?
You mean the decrease of global routes?
etc...
Those are luckily all nicely covered and if something is not they should
be addressed ASAP (read: yesterday).
Also a nice new draft came up today on the ietf lists called
"Application Aspects of IPv6 Transition" see:
http://www.ietf.org/internet-drafts/draft-shin-ngtrans-application-trans
ition-00.txt
I think this is covering most of this discussion.
Greets,
Jeroen