Re: US DoD and IPv6

["Joel M. Halpern" <[e-mail]>]

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