IPv6 woes - RFC

Thu Sep 16 12:58:28 UTC 2021

John you were not the "sole network operator" on the directorate.[1]  
And I'm not saying that there weren't arguments, but I am saying that 
nobody said, “wait for something better.” Rather, everyone was arguing 
for their preferred approach out of the ones I mentioned.

Eliot

[1] https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94

On 16.09.21 14:10, John Curran wrote:
> On 16 Sep 2021, at 5:46 AM, Eliot Lear <lear at ofcourseimright.com 
> <mailto:lear at ofcourseimright.com>> wrote:
>> It's hard to argue that there was no transition plan.  There were in 
>> fact at least three transition plans for the selected approach (dual 
>> stack, 6to4, and tunneling) some of which have been discarded along 
>> the way; while others came to be based on operational experience. 
>> Moreover, the only way to really know that a transition mechanism is 
>> really going to work is to let it out of the lab.  And ALL of the 
>> proposals would have suffered the very same transition pains, because 
>> just as Jeroen has pointed out, the pain stretched all the way to the 
>> application.
>
> Eliot -
>
> The requirement was not for the assertion of multiple “transition 
> plans”, but rather "The protocol must have a straightforward 
> transition plan from the current IPv4.”
>
> "A straightforward plan” – singular.  If you have a link to that plan, 
> please provide it, but until such time I’ll stay with my understanding 
> of events (that being that we completely dropped the ball with regard 
> to providing the operator community with a meaningful transition plan.)
>>
>> I don't think it's reasonable to argue that we should have waited for 
>> some other mythical better proposal to come along.  I don't recall 
>> anyone arguing for that at the time, and there's no reason to believe 
>> that such a mythical proposal would have ever come to be in any 
>> foreseeable time frame.  In fact Erik Fair, Dave Crocker, Tom Kessler 
>> and I argued the very opposite, that we were digging ourselves a hole 
>> with NAT.  Your argument at the time (Interop '95, Vegas) was that 
>> the IETF didn't have the right to dictate address usage to 
>> deployments.  True enough, but then people shouldn't hang their woes 
>> on the IETF.
>>
> Sorry, I was on the IPng Directorate, and there were indeed arguments 
> that we lacked meaningful transition strategy, and that the fig leaf 
> of shipping the responsibility off to “to-be-defined” working groups 
> was irresponsible.
>>
>> As I mentioned earlier, the fundamental issue was that there were no 
>> ng proposals that were in fact substitutable resources for v4, and 
>> NAT was. From there, economics has ruled, arguments be damned.
>>
> As predicted - "As currently envisioned, IPng may not be ambitious 
> enough in the delivery of new capabilities to compete against IPv4 and 
> the inevitable arrival of network address translation devices.  In 
> order to meet the requirement for “viability in the marketplace', IPng 
> needs to deliver clearly improved functionality over IPv4 while 
> offering some form transparent access between the IPv4 and IPng 
> communities once IPv4 address depletion has occurred.”
>
> Sorry, but as the sole “network operator” on the IPng Directorate who 
> lived through thru convenient papering over of the transition 
> requirement firsthand, I’ll have to concur with Randy Bush’s take on 
> this one -
>
>>> "real compatibility with ipv4 was disdained.  the transition plan 
>>> was dual stack and v4 would go away in a handful of years.  the 93 
>>> transition mechanisms were desperate add-ons when v4 did not go 
>>> away. and dual stack does not scale, as it requires v4 space 
>>> proportional to deployed v6 space."
>>>
>>> we are left to make the mess work for the users, while being 
>>> excoriated for not doing it quickly or well enough, and for trying 
>>> to make ends meet financially.”
>
> Anyone who wants to argue that IPng had a viable transition plan best 
> put a hard link to the documented plan in their reply - trying to 
> argue the point without actually citing the alleged  “straightforward 
> plan" is just embarrassing.
>
> Thanks,
> /John
>
> p.s.  Disclaimer: my views alone (although likely shared by many 
> operators upon hearing silence in response to the question:  “Okay, 
> how is this transition really supposed to work?”)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210916/fc47f19b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x87B66B46D9D27A33_and_old_rev.asc
Type: application/pgp-keys
Size: 7386 bytes
Desc: OpenPGP public key
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210916/fc47f19b/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210916/fc47f19b/attachment.sig>