Re: US DoD and IPv6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]