Without getting into the question of whether your suggestion would have
helped anything in terms of transition and interoperability, it shares
one major flaw with the path we did adopt.
There is no incentive to spend resources to get there.
No matter how elegant it is technically, without a benefit for
deployment there is no way to get past very small scale deployment
(some folks will deploy anything to see if it has value, but most won't.)
That is one of the main stumbling blocks that Noel reported publicly for
getting Nimrod off the ground separately from the IPv6 effort. The
operators who had to deploy it did not gain anything.
As long as our path is one of minimal change, we were inherently locked
in to a behavioral set that matched Ipv4. that is what SIP proposed.
That is what IPv6 gave us.
For any proposal to work, there has to be a benefit to folks to use it.
Even before it is ubiquitous. As far as I can tell, we ignored that
question during the 1993-1999 period when we should have been working on it.
We also get ourselves into a mind set of "we need an answer now. There
is no time to do technically hard work." That was a bad call. 5 extra
years spend=t serously working on what the needs were, what the
deployments could be, and what the technology could look like, might
have given us a better path. (No, there is no guarantee. We could have
blown it anyway.)
Yours,
Joel M. Halpern
On 10/10/2010 6:41 PM, Dave CROCKER wrote:
On 10/10/2010 2:51 PM, Steve Crocker wrote:
A compatible solution would have been better, but I don't think
IPv4... --
were designed in a way that permitted a compatible extension.
Oh?
Perhaps:
1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic
upgrade to the IPv4 header, with more address bits, an extensibility
mechanisms for adding fields later, and removal of some bits that
weren't needed.
2. Define the IPv6 address space as the IPv4 address space, with all
zeroes for the higher bits. (In other words, defer more interesting
schemes until later.)
3. Design header translation devices to map between the two formats.
4. Start fielding these implementations. (That could have started by
1994 or so.)
The "gateways" between v4 and v6 would initially be notably for having
almost no work to do and of not losing any information. In particular,
barely qualifies as a "dual" stack.
With this approach, "incompatibility" between v4 and v6 would only occur
when additional addresses, beyond v4's limitations, start to be assigned.
We must deal with the current reality and make it work, but historical
considerations need to factor in the ambitions that dominated during the
many years of design.
The community got ambitious in a fashion that smacked of the
overreaching that is often called second system syndrome (although
counting the Arpanet, this was really a third system...)
d/
[1] http://tools.ietf.org/html/draft-deering-sip-00
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf