[ih] Could it have been different? [was Re: vm vs. memory]

[brian.e.carpenter at gmail.com (Brian E Carpenter)]

On 26/10/2017 09:27, Dave Crocker wrote:
> On 10/25/2017 12:10 PM, Brian E Carpenter wrote:
>> On 26/10/2017 02:13, Noel Chiappa wrote:
>> ...
>>> Needless to say, had I still been on the IESG
>>> at the time of the IPv6 process, that design would _never_ have been accepted
>>> - 'over my dead body'.
>>
>> Counterfactuals are always fun. However, I believe that the sad fact is that
>> *no* IPng solution of any kind whatever could in practice have been deployed
>> smoothly. Why? Because of Tim Berners-Lee, Marc Andreessen and a few other
>> people. By the time any IPng code could have been available (the first
>> commercial release of IPv6 code was in 1996), the growth rate of IPv4 and
>> the inevitability of NAT44 made deployment very hard indeed; the incentives
>> were all for deploying more and more IPv4, and remained that way for 15+
>> years.
>>
>> Now that IPv4 is truly hitting its limits, the main operational complaint
>> against IPv6 is that it's too different from IPv4. But the incentives are
>> finally shifting in IPv6's favour, like it or not.
>>
>> The reason that there is still thrashing in IPv6 transition discussions
>> is that the original IPv6 transition plan was designed for a different world.
>> I suspect that the root cause of the IPv6 issues that John Levine mentioned
>> lies there.
> 
> 
> Certitude about hypothetical pasts also is fun, but possibly 
> distracting.  In this case, the premise is that nothing could have 
> dislodged IPv4.  Yet we have quite a few examples of other major 
> infrastructure upgrades -- and at different levels -- that worked well, 
> or at least that worked.  There should be some respect for those 
> accompishments and some attempt to understand why they succeeded when 
> others -- such as IPv6 -- has not.
> 
> To work, an upgrade must either have no effect on the rest of the 
> installed base, or it must have strong adoption incentives for those 
> doing the adopting.  IPv6 has always suffered from more idealism in its 
> incentives than immediate, operational pragmatics.
> 
> By way of reiterating a hypothetical alternative IPv6 approach that I've 
> offered a number of times:
> 
> If Deering's original, simple IPv6 -- which only did exactly what was 
> needed and did it cleanly, with a hook for /future/ enhancements -- had 
> been adopted pretty much as is, the core IPv6 code would be very nearly 
> identical to IPv4 code.
> 
> If the initial administration of address space were to apply the 
> /existing/ IPv4 addresses -- reserving the remainder for later -- then 
> v4/v6 interoperability would have required trivial gatewaying.  By the 
> time more address space was actually needed, there would be a 
> non-trivial amount of IPv6 code in operation.
> 
> The hand-wave, here, is for the application interfaces to IPv6 and, yes, 
> that's additional, essential detail.  

Right. I remember doing a tour of the offices close to mine at CERN,
in around 1995, asking everybody who'd written code using the socket
interface how they stored IP addresses - in a struct or in an integer?
They all said "integer". That was the day I knew this would be hard.

> But my real point is that careful, 
> focused attention to adoption as an incremental enhancement to the 
> existing IPv4 infrastructure -- rather than inventing a completely 
> independent, parallel stack -- then we could have started getting IPv6 
> operational experience long before the end of the 1990s.

It's possible. But this wasn't perceived as an issue until the HTTP
explosion was well under way.

   Brian