�Hola!
> If you want to port in an IPv4 and IPv6 independent manner you will use
> the tools as currently specified. There is not protocol that will matter
> besides IPv4 and IPv6 for at least the next 10 years.
10 years? If we're thinking so short-term something is bad. And if in 10
years there are other protocols we'll be better going full speed to the
AF independence.
I wasn't thinking myself being involved with future transitions, but
maybe my children or grandchildren will (and i'm not even married yet,
maybe my grandchildren get old enough to be involved with that in 50
years from now)
> The debate is not
> technical but where the future will be. This makes it hard.
The question is "Will IPv6 work forever?", if the answer is yes, then there
is nothing to talk about, if the answer is no (and I think that way) then
we should try to help the next transitions to be easier, using what we have
learned now.
Now we need to port several thousands of applications, in 50 years there will
be tens of thousands. If my grandchildren will be there, I'd like they could
work with the interesting stuff (designing the protocol, implementing the
stacks) and not with the boring, almost mechanical tasks (changing all INET6
for INET10)
We cannot think for only 10 years, 10 years is almost the time we've spent by now
in the IPv4 -> IPv6 transition, and it is just starting (ok, maybe now things
go faster and it will be complete in 5 years more, but yet we're at the start)
It's unwise to look so little in the future.
> API folks
> have debated this the answer is as is specified now.
It seems from the discussion that there is not a real consensus, but just a
"that's how it is being done, don't change it".
For the ones who prefer to just look a few years in the future, I'll say let
the IPv4 mapping enabled, but that should be done in a way that doesn't
generates problems for the people that prefer to look further.
So, while things don't change, there is a problem. And that problem ought to
be solved. I've proposed several ways to solve it and allow more choices to
the programmers and OS implementors.
> /jim
HoraPe
---
Horacio J. Pe�a
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
