Date: Mon, 25 Jun 2001 13:26:17 -0300
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| 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.
Unfortunately this requires crystal ball gazing.
I partly agree with Jim - not where he said that 10 years is nothing
(he seems to have forgotten that the IPv4 API that is being, only partly,
replaced here was invented 20 years ago already...) but do agree that we
cannot possibly plan now to handle the next set of problems.
The API transition for IPv6 largely concerns dealing with the different
address type - if/when we need a new protocol, the least likely thing of
all we have in IPv6 to be worrying about will be the address.
It may be that in some future protocol, applications will be required to
determine and set a flow label for all packets/connections - nothing we're
now defining would have applications doing that (even if we did, we have
no idea what form the flow label of that far future time might be).
Or, it may be that (as was proposed by PIP) applications need to discover and
set the route to the destination, with the "routers" being converted to being
just very fast forwarders, not running any routing algorithms at all.
Since we have no idea how that might be done, or what the result would look
like, we can't plan for that today either.
Of course, since I can imagine both of those already, they're most likely
not going to be the major turning point which requires a new IP level
protocol. What it would be is likely to be something that now we can't
even guess at. Given that, how can we possibly design an API today to
handle it? (Unless we make the API so dumb, that the application gets
no control at all).
But more than that, it is perhaps more likely that the next revolution will
be transport protocol based, and it will be the API that deals with the
transport interface, rather than the part of it that deals with TCP or UDP
(or something entirely new) will be what needs to alter. That is, perhaps
port numbers will be gone completely from a future transport interface, to
be replaced by something else completely different. Who knows?
Because of all this, we cannot possibly make an AF independent API that
handles anything more than the protocols that we know of today. Perhaps
we can also make it adaptable to a few things that we can guess now might
happen in the future (but for any of those that we now think likely, we'd
be better off to simply include them now, and avoid another transition
later - but there seems to be little we can agree on might be needed, beyond
what is in IPv6) so, even that doesn't seem productive.
And then given that, what is needed is to handle what we see as being
important to handle of today's protocols - and that means IPv4 and IPv6.
There's nothing else that almost any code which is going to use this API
is going to deal with (we could add CLNP or something, but the applications
that use CLNP and the applications that use IP are almost a disjoint set,
there's almost nothing to be gained by unifying them).
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
