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

Brian E Carpenter brian.e.carpenter at gmail.com
Wed Oct 25 14:26:18 PDT 2017


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



More information about the Internet-history mailing list